39 posts tagged with "Bug Fix"

When a pull request plans changes across many components, you need to see what will change, which plans failed, and which components need no action. Opening a separate log for every component makes that review slow. Atmos brings back the normal component summaries beneath the bulk-plan overview so you can review those results together in your CI summary or pull request comment.

A component that inherits metadata.component from a base should behave like one that sets it directly. Until now, parts of Atmos still treated it as a component named after the instance, which caused failed lookups and missed affected components. Fixing that also changes the backend key Atmos generates for these components, so existing projects may need one step when they upgrade.

We published incorrect artifacts in the 1.233.0 and 1.233.1 releases.

Release engineering controls versions, builds, signatures, provenance, and distribution. Application tests alone do not prove that this process publishes the correct release.

We test the release process in CI alongside Atmos. Tests check release rules, artifact verification, and publication without real releases.

Replacing legacy naming patterns can accidentally select a different Terraform workspace, while a copied schema can reject configuration supported by your installed Atmos version. The Atmos Doctor command now checks naming migrations before applying them and identifies local Atmos schema overrides for review.

An RDS instance's latest restorable time can advance between Terraform plans even when its configuration has not changed. That timestamp can make a plan comparison fail and interrupt deployment verification. Atmos now supports configured attribute exclusions for both comparisons.

Comparing debug logs is harder when ANSI color escapes appear in the files, even after you ask for plain output. Atmos now consistently honors global color opt-outs and adds an independent log color setting, so you can save plain logs while keeping your terminal UI colored.

Large infrastructure repositories can contain a few components with much larger settings than the rest. Grouping uploads by component count could still produce an oversized request and fail with HTTP 413. Atmos now sizes affected-stack and instances upload batches by their actual serialized bytes and recovers with smaller requests when the server rejects a batch.

Every step in a custom command or workflow passes through Go templates before it runs. That is convenient until a script needs literal braces: a Starlark format string, a Helm-style placeholder, or {{ }} text meant for another tool. Escaping does not help, because a custom command renders its steps more than once, and atmos.yaml refused the !literal function that stack manifests already support. Custom-command inputs had rough edges too: an argument containing a comma was split in two, integer flags never reached the step, and a step's timeout: was not enforced.

Reviewing a CloudFormation deployment in CI means finding the pending changes, the deployment result, and any drift in a stream of job output. Atmos now presents those results as native job summaries, alongside fixes for dependency ordering, sensitive outputs, and template delivery.

CI should install the artifacts reviewed and committed with a project. Ordinarily, Atmos verifies artifacts against the lockfile's recorded checksums, but it can still accept and record a new artifact when a tool or platform entry is missing.

Enable toolchain.frozen_lock_file: true in CI and security-sensitive environments to reject those missing entries and prevent lockfile writes. That way, you can prepare and review lockfile updates before running CI.

This update makes project configuration consistent across invocation directories and keeps automatic installs from changing declared dependencies. The same project paths and declarations apply whether a developer or CI runs the command.

A container component's build.context and dockerfile looked like ordinary relative paths, but they weren't resolved against anything in particular — they resolved against whatever directory your shell happened to be in the moment you ran atmos container build. Run it from the repo root and it worked. Run it from a subdirectory, a CI job with a different working directory, or a script that changes directories first, and the build silently picked up the wrong Dockerfile or found nothing at all. Setting components.container.base_path didn't help — that option was accepted but quietly ignored.

You add platforms: [linux/amd64] to a container build step, run it, and nothing happens differently. No error, no warning — the field is just gone, like it was never written. You spend ten minutes checking your YAML indentation before realizing the field name was never real to begin with.

Editing a config value from the command line is supposed to be the easy path. Type atmos stack set vars.replicas 5, expect a 5, move on. Except a value like that used to come back out the other side as the string "5" unless you remembered to pass --type=int — and for atmos stack set specifically, that was true every single time, no matter what was already there. A true became "true". A number stayed a number only if you told the CLI so yourself.

Kustomize expects the files it consumes to have exact, reserved names. A remote base or component can only be included if the location it points to contains a file with one of a handful of recognized names (kustomization.yaml is the common one) — that's not configurable on Kustomize's side. So when a value only Terraform knows — a security group ID, a Route53 zone ID, an ARN — needs to land inside a Kustomize-managed GitOps repo, teams are usually stuck hand-editing the overlay after every apply, or routing the value through a separate tool just to produce one correctly-named file.

We've fixed an issue where YQ default values (using the // fallback operator) in !terraform.state and !terraform.output YAML functions were not being evaluated when components weren't provisioned or outputs didn't exist.

On macOS, Atmos would sometimes install a verifier CLI (like cosign, used to check signatures on downloaded toolchain binaries) through verifier_install: auto, checksum-verify it successfully — and then have the OS kill it the instant Atmos tried to run it. Gatekeeper and AMFI re-validate a downloaded binary's code-signing trust on every execution, not just the first Finder launch, so a checksum match alone wasn't enough to let a freshly downloaded, ad-hoc-signed release asset actually run.

You pinned aws/aws-cli in your toolchain, ran atmos toolchain install, and saw a green checkmark — then aws --version died with Failed to load Python shared library. Or you pinned nodejs/node and the install never finished at all, warning about "unknown type" and a file it couldn't find. The tools were right there in the registry, aqua installed them fine, but Atmos couldn't.

That's fixed. Multi-file tools now install completely and actually run.

A component with an oci:// source and provision.workdir.enabled: true failed the moment you ran any Terraform operation against it. JIT auto-provisioning (the before.terraform.init hook) failed with go-getter's download not supported for scheme 'oci', even though atmos vendor pull handled the exact same source fine. Registries distributing modules in OpenTofu's native OCI module-package format couldn't be pulled by either path at all.

Security scanner hooks (Checkov, Trivy, KICS) now write their findings to the GitHub Actions job step summary automatically — so scan results show up in the pipeline run instead of being buried in the atmos terraform plan log stream. The official Atmos Docker image was also updated so Checkov runs without a glibc error.

The atmos describe affected command now compares every provisioned component section between refs — including providers, required_providers (provider versions), generate, backend, auth, and command. Previously, changes to these sections were silently missed.

Atmos now supports before.terraform.init and after.terraform.init lifecycle hooks, and --skip-hooks is finally honored for before- hooks across plan, apply, and deploy.

atmos terraform plan --all and apply --all now execute components in dependency (topological) order, as originally documented. Until this fix, the --all flag was processing components in a non-deterministic order — the dependency-graph implementation that landed with PR #1516 was reachable from tests but never wired into the CLI dispatcher.

Three documented flags on atmos list instances were silently ignored: --stack, --filter, and --query. They now do what the docs say.

Fixed an issue where retrieving values from Artifactory stores would fail when using nested paths, and corrected store documentation to accurately reflect supported backends.

The --chdir flag now correctly isolates configuration loading when changing to a directory with its own Atmos configuration.

Atmos now correctly detects component file changes when running atmos describe affected. A regression introduced in v1.195.0 caused changes to Terraform, Helmfile, or Packer component files to not be detected when atmos.yaml was located in a subdirectory of the git repository (e.g., when using atmos -C path/to/project).

Atmos now correctly detects file changes in components that use the source attribute for just-in-time vendoring. Previously, components vendored from remote sources were not properly tracked for affected detection.

Interactive component selection now filters out non-deployable components.

The atmos list components command now correctly shows unique component definitions, supports stack filtering, and uses a new dedicated configuration namespace.

The file-scoped locals feature introduced in v1.203.0 now correctly resolves {{ .locals.* }} templates in stack configurations. Previously, locals were defined but not integrated into the template processing pipeline, causing templates to remain unresolved.

The !terraform.state YAML function now correctly reads Terraform state when workspaces are disabled (components.terraform.workspaces_enabled: false in atmos.yaml). Previously, Atmos looked for state files in the wrong location, causing the function to fail.

Atmos now automatically detects when your AWS IAM User credentials have been rotated or revoked and prompts you for new credentials inline. No more persistent authentication failures after credential rotation. Plus, improved guidance when credentials expire.

Several terraform CLI flags that were not working after version 1.202.0 have been restored. These flags were inadvertently broken during the command registry migration.

Atmos now provides clear, actionable error messages when your Terraform components contain HCL syntax errors, instead of the misleading "component not found" message.

Atmos now validates that remote backend configurations are not empty before generating backend files. This prevents invalid Terraform configurations that would fail during terraform init.

Atmos now properly handles nested maps in Terraform backend configurations when using HCL format. This fixes an issue where complex backend settings like assume_role were silently dropped.

We've fixed a critical bug in how Atmos handles arguments passed to custom commands via {{ .TrailingArgs }}. This fix improves security and ensures whitespace and special characters are preserved correctly.

Updated the Atmos Pro integration to use query parameters for the instances API endpoint, fixing issues with stack and component names containing slashes and improving API compatibility.

We've identified and corrected a regression in Atmos where the pager was incorrectly enabled by default, contrary to the intended behavior documented in a previous release.