cloudposse/atmos v1.226.2-rc.0

on GitHub

• Relocate the default golangci-lint cache and tmp directories from inside each worktree (.golangci-cache/, .golangci-tmp/) to the OS user cache directory: <user-cache>/atmos-lint/<worktree-hash>/{cache,tmp} (~/Library/Caches/atmos-lint/... on macOS).
• The <worktree-hash> (first 12 hex chars of SHA-256 of the absolute worktree path) preserves #2701's per-worktree isolation of golangci-lint's single-instance lock — the dirs just no longer live under the worktree tree.
• ATMOS_LINT_SHARED_CACHE=1 opt-out and explicit GOLANGCI_LINT_CACHE overrides behave exactly as before.
• Tests updated/added: new-location assertions, hash determinism + cross-worktree non-collision, user-cache-dir failure propagation.
• Adds docs/fixes/2026-08-24-fsmonitor-worktree-saturation.md with the full measured diagnosis.

why

#2701 put a 156MB / ~37k-file cache that churns on every lint run inside each worktree — directly under any filesystem watcher observing that tree (git fsmonitor, Conductor's watchexec). At multi-worktree scale this saturated macOS FSEvents: git status measured 2.9s–timeout (>2min) with fsmonitor vs 0.04–0.15s without, and every pre-commit run pays that tax dozens of times, stretching commits to minutes. Moving the churn outside the watched tree makes this impossible to re-trigger on any machine, regardless of watcher configuration.

Measured after the fix: cold lint:precommit 9.1s, warm 1.5s, no cache dirs created in the worktree; a full commit through all pre-commit hooks + signing completes in ~5s.

references

• #2701 (perf(lint): isolate golangci-lint cache and lock per worktree) — introduced the in-worktree location this PR relocates; its lock-isolation intent is preserved
• docs/fixes/2026-08-24-fsmonitor-worktree-saturation.md — full diagnosis, timeline, and machine-level remediation notes

Summary by CodeRabbit

• Bug Fixes

  • Improved linting in Git worktrees by storing cache and temporary files in isolated user-cache locations.
  • Reduced unnecessary file-monitor activity caused by lint-related file churn.
  • Preserved support for shared caches and explicitly configured cache locations.
  • Improved error handling when cache locations cannot be resolved or created.
  • Added safeguards to keep cache data separated between worktrees.

• Documentation

  • Added troubleshooting guidance for worktree file-monitor saturation and remediation steps.

• Set "moby": false on the docker-outside-of-docker devcontainer feature in .devcontainer/devcontainer.json.

why

The Codespaces Prebuilds workflow (prebuild) fails on every push to main. Example failed run: https://github.com/cloudposse/atmos/actions/runs/32431458655/job/96623702606

The base image mcr.microsoft.com/vscode/devcontainers/base:debian now resolves to Debian 13 (trixie), which does not package moby-cli. The docker-outside-of-docker feature defaults to moby: true and errors out during the prebuild image build:

(!) The 'moby' option is not supported on debian 'trixie' because 'moby-cli'
    and related system packages are not available in that distribution.
(!) To continue, either set the feature option '"moby": false' or use a
    different base image (for example: 'debian:bookworm' or 'ubuntu-24.04').
ERROR: Feature "Docker (docker-outside-of-docker)" failed to install!

Setting moby: false makes the feature install Docker CE instead. This is safe and non-redundant: the devcontainer Dockerfile already configures Docker's official apt repo and installs docker-ce/docker-ce-cli, so no moby packages were ever needed — the feature only wires up the forwarded host Docker socket.

references

• Failed run: https://github.com/cloudposse/atmos/actions/runs/32431458655/job/96623702606
• Feature docs: https://github.com/devcontainers/features/tree/main/src/docker-outside-of-docker

Summary by CodeRabbit

• Chores
  • Updated the development container configuration to install Docker CE instead of Moby on Debian 13.

• Bump the Docker Build step in .github/workflows/build.yml from cloudposse/github-action-docker-build-push v3.1.0 (02993d67) to v3.2.1 (ff59bd5).

why

• The release / Build and push Docker image for Atmos CLI job has been failing on the post-build Docker Inspect summary step with jq: error (at inspect.json:79): Cannot iterate over null (null) → exit code 5, even though the image builds and pushes fine.
• Root cause was in the action itself: its summary step fed docker inspect fields (.Config.Entrypoint, .Config.Cmd, .Config.Env, .RootFS.Layers) straight into jq's join/.[]/to_entries, all of which iterate. Atmos's image is FROM debian:trixie-slim with no ENTRYPOINT, so .Config.Entrypoint is null and jq aborts; under the default bash -e shell that fails the whole step.
• Fixed upstream in cloudposse/github-action-docker-build-push#111 (guards each iterating expression with // []), released as v3.2.1. Verified ff59bd5 contains all four guards. This bump pins Atmos to that release so the release job's summary no longer crashes.

references

• Failing run: https://github.com/cloudposse/atmos/actions/runs/32415649296/job/96577335200
• Upstream fix: cloudposse/github-action-docker-build-push#111
• Release: https://github.com/cloudposse/github-action-docker-build-push/releases/tag/v3.2.1

Summary by CodeRabbit

• Chores
  • Updated the Docker build workflow to use a newer action version, improving build pipeline maintenance and reliability.

TF_CLI_ARGS_apply configured through atmos.yaml no longer reaches Terraform-exec's internal output command. Post-apply output-store hooks can retrieve and publish the declared Terraform output after a successful apply.

Why

Terraform-exec rejects manual command-specific argument variables during its output invocation. Atmos filtered inherited variables but restored them from the resolved component environment. The output path now ignores TF_CLI_ARGS and TF_CLI_ARGS_* while preserving normal environment variables and TF_VAR_* values.

Validation

• Added a regression test for apply and plan CLI arguments while preserving TF_VAR_*.
• go build ./...
• atmos fix coverage origin/main
• Patch lint: 0 issues.

Closes #2990

Summary by CodeRabbit

• Bug Fixes

  • Fixed Terraform output retrieval failures caused by command-specific CLI argument environment variables.
  • Preserved supported component variables, including TF_VAR_* values, while excluding TF_CLI_ARGS settings from output processing.

• Documentation

  • Added documentation describing the fix and its expected behavior.

• atmos packer now sets up Atmos Auth the same way terraform and helmfile do: it creates and authenticates the component AuthManager, passes it to ProcessStacks, and injects the resolved identity's credentials into the packer subprocess environment before executing.
• Extracted the credential-injection helpers (resolveDefaultIdentity and the renamed prepareComponentAuthEnvironment, formerly prepareHelmfileAuthEnvironment) into internal/exec/utils_auth.go so helmfile and packer share one path instead of duplicating it.
• Added regression tests (internal/exec/packer_auth_test.go) via two test seams: one asserts a non-nil AuthManager is passed to ProcessStacks; the other asserts an injected credential reaches the packer subprocess env.
• Added a fix record under docs/fixes/.

why

• atmos packer build ran completely unauthenticated when relying on Atmos Auth. internal/exec/packer.go called ProcessStacks(..., nil) (nil AuthManager) and never called PrepareShellEnvironment, so no AWS credentials ever reached the packer process. Its datasources failed with:

  Error: Datasource.Execute failed: No valid credential sources found
  

• Both other component executors already do this — terraform via setupTerraformAuth + auth.TerraformPreHook, helmfile via SetupComponentAuthForCLI + credential injection — so packer was the odd one out, even though the AuthManager interface docstring explicitly lists Packer as a supported subprocess.

• Verified against a real workload: atmos packer build <component> -s <stack> now proceeds into the AMI build (VPC prevalidation, keypair creation, etc.) where the stock binary failed with the credential error.

references

• Mirrors the existing helmfile auth flow in internal/exec/helmfile.go.
• AuthManager contract: pkg/auth/types/interfaces.go (PrepareShellEnvironment — "Use this for all subprocess invocations: Terraform, Helmfile, Packer, ...").
• Fix doc: docs/fixes/2026-08-23-packer-atmos-auth-credential-injection.md.

Summary by CodeRabbit

Bug Fixes

• atmos packer build now honors configured authentication settings.
• Credentials for authenticated components are automatically resolved and provided during Packer builds.
• Authentication behavior is now consistent across supported component workflows.
• Added regression coverage to improve reliability and prevent authentication regressions.

Documentation

• Added guidance for configuring authentication when using Packer builds.
• Updated workload and continuous integration examples with clearer, generic descriptions.