Skip to main content

30 posts tagged with "Bug Fix"

Bug fixes

View All Tags

Consistent Toolchain Paths and Stable Version Declarations

· 4 min read
Erik Osterman
Founder @ Cloud Posse

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.

Container Build Paths Depended on Where You Ran Atmos From

· 3 min read
Erik Osterman
Founder @ Cloud Posse

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.

Smarter Type Handling for `atmos config set` and `atmos stack set`

· 4 min read
Erik Osterman
Founder @ Cloud Posse

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.

Injecting Terraform Values into Kustomize Without Hand-Editing Overlays

· 3 min read
Erik Osterman
Founder @ Cloud Posse

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.

Fixing Gatekeeper SIGKILLs on Downloaded Toolchain Verifiers

· 2 min read
Erik Osterman
Founder @ Cloud Posse

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.

Toolchain now installs aws-cli, Node, and other multi-file tools correctly

· 3 min read
Brian Ojeda
Contributor

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.

oci:// Sources Now Work with JIT Auto-Provisioning

· 2 min read
Zack A
Contributor

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.