Our workflow examples now use GitHub Actions' container option to run job steps inside the official ghcr.io/cloudposse/atmos Docker image instead of installing Atmos via a separate GitHub Action. This is faster because it skips reinstalling Atmos on every execution — Docker images are cached on runners, so subsequent runs start almost instantly.

We strongly recommend this approach when running large-scale workflow dispatches. GitHub API tokens are capped at 5,000 requests per hour per app, and eliminating install steps reduces API calls per workflow run. Declare the container once at the job level — no install step, no version pinning in action inputs, no wrapper scripts. See the updated workflow examples for the complete configuration.

jobs:
  affected:
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/cloudposse/atmos:${{ vars.ATMOS_VERSION }}
    defaults:
      run:
        shell: bash

The atmos describe affected command now works with a single flag. Atmos natively understands GitHub's CI environment — it detects the base branch, determines the correct commit SHA for comparison, and handles merged pull requests automatically.

Before, detecting affected stacks required shell scripting to calculate which SHA to use for a pull request, conditional logic to handle open vs. merged PRs, and a separate step to compute the parent commit. This is part of our commitment to eliminate shell foo from most operations involving Atmos. Now it's just:

atmos describe affected --upload

That's it. The Atmos CLI handles everything else. See the Affected Stacks workflow for the complete example.

Existing workflows continue to work — these are simplifications, not breaking changes. We recommend migrating to the new patterns for cleaner, more maintainable workflows. For a fully working reference, check out the Atmos Pro Example Advanced repository.