Skip to main content

Proposed: Use GitHub Actions with Atmos

Date: 14 Apr 2022

Needs Update!

The content in this ADR may be out-of-date and needing an update. For questions, please reach out to Cloud Posse

  • The proposal has already been adopted, and this ADR needs to be updated to reflect the final decision.

Status

DRAFT

Problem

Smaller, bootstrappy startups don’t have the budget for Spacelift. There are things in atmos that we can do (e.g. workflows) that are easier to implement in conventional manners than the rego-based approach in Spacelift.

Context

Considered Options


  • Include support for terraform plan -destroy for deleted stacks or components

  • atmos terraform apply

  • Upon approval, trigger an “apply” by pulling down the corresponding “planfile” artifact from S3; they may be more than one planfile; abort if no planfile

  • Run atmos terraform apply on the planfiles in the appropriate order

  • Discard planfiles upon completion

  • Workflows for complex, coordinated sequences of operations (e.g. to bring up a full stack, one component at time)

  • Conflict resolution

  • Locking strategy for components / planfiles. How do we determine the latest planfile?

  • Implement a GitHub Action that when used together with branch protections prevents merging of pull requests if other unconfirmed changes are pending deployment and affect the same stacks.

  • This is the most complicated part of the solution. A “one cancels all” type of strategy will probably need to be implemented. We have to ensure planfiles are applied in sequential order, and any planfiles needs to be invalidated (or replanned) if upstream commits are made affecting the stacks

  • Drift Detection

  • Implement cron-based automatic replans of all infrastructure under management. https://docs.github.com/en/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#onschedule

  • Trigger webhook callbacks when drift is detected (e.g. escalate to Datadog)

Risks

Mocking GitHub Action Workflows

Checks UI. Each job is a component. Each step is an environment.


name: "plan"
on:
pull_request:
types: [opened, synchronize, reopened]
paths:
- stacks/*
- components/*
jobs:
atmos-plan:
runs-on: self-hosted-runner
steps:
- name: "Checkout source code at current commit"
uses: actions/checkout@v2
- name: Atmos do everything
runs: atmos plan do-everything


- name:
id: prepare
env:
LATEST_TAG_OS: 'alpine'
BASE_OS: ${{matrix.os}}
run: |

Decision

DECIDED:

Consequences

References