29 posts tagged with "Bug Fix"

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.