73 posts tagged with "Enhancement"

Gomplate's experimental functions are now available in Atmos stack manifests. Network calculations can be expressed in stack templates, reducing hardcoded CIDRs and IP addresses across environments.

Reading about a feature should lead directly to trying it. Finding its example directory, installing Atmos, and assembling the first commands adds unnecessary work. Changelog posts with runnable examples, command documentation, and individual example pages now include a quick start with installation instructions and copyable commands.

The templates.settings.delimiters setting changes the delimiters that Atmos templates use, but it only ever reached stack manifests. Workflow, custom command, and lifecycle hook steps kept parsing {{ }} no matter what you configured. A project that moved to [[ ]] to keep Go-template-looking text such as a docker inspect --format '{{.State.Status}}' argument out of the template engine still had to mark each of those step fields !literal, or fail with a template error.

A CI job fails, and the run page says only "Process completed with exit code 1." To learn why, you open the job, scroll through the log, and hunt for the one error that matters. When the failure is a policy denial, the rule that blocked the run and the reason its author wrote are in that log too, out of sight of the person reviewing the pull request. Atmos now reports a failed command as a CI annotation, so the reason appears on the run page.

Preformatted Terraform tables make it difficult to group variables or reproduce an existing README design. Atmos README templates can now access native Terraform objects through a terraform function, so you can render definition lists, badges, and collapsible sections yourself.

The past year has changed how we build Atmos. Advances in AI have accelerated our development and helped us bring many new capabilities to the project. Some needed more time and real-world experience before they were ready for broad adoption. We introduced the experimental designation to make that maturity visible and help you decide which features were ready for everyday use.

Since then, we, our customers, and the community have put many of these features to work in production. That use has brought valuable feedback. Interfaces have stabilized, functionality has been validated, and feedback has increasingly shifted from critical problems toward refinements and nice-to-haves.

We're graduating Atmos CI, Atmos Auth, Atmos Toolchain, Atmos Emulator, and source vendoring to stable. These capabilities have demonstrated stable interfaces and real-world use; this release formalizes their supported status. Other features will keep the experimental designation while we continue assessing them.

You pin hashicorp/terraform 1.15.8 in .tool-versions, run atmos terraform plan, and Atmos quietly runs whatever Terraform happens to be first on your PATH — a Homebrew upgrade, a teammate's tfenv shim, or an older binary on a CI runner. The Terraform versions guide promised the pinned version; components didn't deliver it. Now every command and component uses .tool-versions as its baseline.

Many organizations enforce an Azure Policy that rejects any Key Vault secret created without an expiration date and a set of tags. It is a sensible governance rule, and it blocks every write that doesn't comply. Until now, that ruled out using Azure Key Vault as an Atmos store in those environments: Atmos wrote the secret value and nothing else, so the policy denied the request.

The Azure Key Vault store now accepts labels and expires options, and applies them to every secret Atmos writes.

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.

A local plan rarely depends on infrastructure that is entirely missing or entirely deployed. For example, the VPC exists, the database has not been created yet, and the cluster is somewhere in between. Until now, component mocks forced an all-or-nothing choice: with --use-mocks, every Terraform lookup returned its mock, even for components whose real state was sitting in the backend.

By default, --use-mocks now treats mocks as fallbacks. Real state wins whenever it exists, and a mock fills in only for a component that has not been provisioned or an output that is missing.

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.

Waiting for each component download to finish before the next begins adds up in large repositories. Atmos vendoring now prepares independent packages concurrently and shows their progress together, while keeping destination writes in declaration order.

Workflows and custom commands can invoke Atmos many times, repeating startup banners and experimental warnings before each step. Those repeated notices make it harder to find the output that matters. Atmos now shows each experimental feature's warning once every 24 hours by default and suppresses repeated startup banners in child invocations.

A component can have several labels, while a variable may need only one value. The !labels function now accepts a key to read a single component label, with an optional fallback when that label is absent.

Infrastructure graphs often include dependencies that are useful when present but should not block an environment when a component is intentionally absent or disabled. Treating every dependency as mandatory forces stack-specific workarounds and makes reusable manifests harder to share.

Git tags on GitHub almost always carry a v prefix — v1.228.0 — because that's the convention both git tag and GitHub releases nudge toward. Package manifests, on the other hand, almost never want that prefix: package.json, plugin manifests, and marketplace listings all expect bare semver. Whenever a version comes from GitHub and needs to land in one of those files, something has to strip the v first.

Atmos lets you configure the Kubernetes namespace where a Helm release should be installed. This prevents charts that do not specify a namespace from being installed into default.

That namespace may not exist. Native Helm creates it for you automatically, so a release deploys in a single operation instead of requiring a separate command, component, or workflow to create the namespace first.

Sometimes, though, the deployment should not be creating namespaces at all.

Atmos's toolchain has had a lockfile for a while. The lockfile records the exact resolved artifact and checksum for each platform. A package manager's lockfile pins a dependency tree the same way. But the lockfile was opt-in. The setting was not documented anywhere a user could find it. Almost nobody turned it on. Almost nobody's installs were actually reproducible. The installs only looked reproducible, because the version string matched.

Terraform components already recover from a transient error automatically — a 502, a dropped registry connection, an S3 backend timeout. Helmfile, Packer, and Ansible components in that same pipeline did not. The exact same class of failure that Terraform shrugged off would still fail your Helmfile sync or Ansible playbook outright, because a retry: block on either was silently inert. Now all four component types share the same retry engine.

Component retry already recovers a single component from a transient error: a 502, a dropped registry connection, a flaky provider lookup. The hard part was sharing that same policy across every component in a stack. You'd copy the same retry: block onto each component, wire up a shared abstract base component just to hold it, or set up a mixin. Now you can define the policy once at the stack level, and every component in that stack inherits it automatically.

Centralizing shared configuration in one private Git repository, and reusing it across projects, is not a new idea. Mergify and Dependabot both support extending a project's configuration from a shared repository. Doing the same for a general-purpose tool usually means a git submodule or subtree, and both are cumbersome. Atmos supports this natively: a project's atmos.yaml or stack manifest adds a remote import, a git:: URL that points at the centralized repository, with no submodule or subtree involved.

Resolving that import still had rough edges. Git fetch authentication was separate from a developer's GitHub CLI session, so gh auth login alone was not enough for a private import. A broken import failed silently: a tag name with a typo, an unreachable host, or a token without read access all added nothing to the configuration, with no warning. And a git:: import with a subdirectory re-cloned on every single command, even when nothing had changed.

Atmos already reused a developer's GitHub CLI session for other GitHub operations, such as toolchain installs. Atmos now reuses that same session for private git:: imports too. This applies to both stack configuration imports and atmos.yaml configuration imports. Atmos also warns you when an import fails. Atmos also lets you cache imports to avoid unnecessary re-fetching.

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.

Large stacks eventually turn into a shared bottleneck. Network, platform, and application owners all need to contribute components, but putting every change in one manifest makes reviews noisy and parent-level configuration easy to accidentally share.

Atmos now lets multiple top-level manifests represent one logical stack while keeping each manifest's components and parent scope independent.

Initializing a project should establish a useful local starting point, not leave a developer with an empty directory and a list of conventions to reconstruct. Modern development platforms provide an initialization workflow: developers select a known-good example or template, create the project locally, and make the next action obvious. Atmos provides that workflow for infrastructure projects.

The atmos init command initializes an Atmos project from a template chosen for the job at hand: a minimal cloud-agnostic project, an AWS application SDLC project, or a cloud landing zone. Each template creates the configuration, structure, and operational path appropriate to that project rather than asking every team to assemble it from scratch.

You set mcp.enabled: true, ran atmos mcp start, and got: failed to initialize AI components: tools are disabled. MCP was on. Why did anything else need to be "enabled" for a command whose entire job is exposing tools?

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.

Reading !terraform.state and !terraform.output can fail to resolve for a dozen different reasons — the backend hasn't been applied yet, your credentials aren't configured, you don't have access to the bucket, or the state you're reading just isn't the latest. Any one of those, on any one component, used to abort the entire list/describe command — every other stack you did want to see disappeared behind one unrelated failure.

The list and describe commands now degrade gracefully by default: an unresolved value is shown as (computed) instead of aborting the command, with a one-line summary telling you how many values were affected.

Atmos custom commands now support path-based names. Instead of writing a deeply nested command tree just to describe a command path, you can put the full command path in name.

The result is easier to read, easier to review, and keeps the same recursive merge behavior that existing custom commands rely on.

A workflow fails in CI. You open the run and you're staring at two thousand lines of undifferentiated output — terraform init, plan, and apply from every step mashed into one endless scroll, with no marker for where one step ends and the next begins. Finding the step that actually broke means scrolling and squinting.

Atmos now folds each workflow and custom-command step into its own collapsible, named log group. You see the list of steps up front and expand only the one you care about.

Atmos help showed too much at once. A simple command like atmos terraform plan --help explained the command, its examples, its own flags, compatibility flags, and every inherited global flag, which made the options you actually needed harder to find.

Topic-specific help fixes that by making default help focused, while keeping usage examples, command flags, and the full reference one flag away.

Atmos help output now separates built-in commands from custom commands, and error output now makes explanations easier to scan without adding extra headings.

Human logs are useful while you are watching a command run, but they are not enough when you need to diagnose subprocess execution, CI failures, or agent runs after the fact.

Custom command steps can now read their own command-line flags through {{ .Flags.<name> }}, and the table step templates its data, columns, and title per-step. Together they let you build flag-driven runbooks — rich, dynamic output assembled declaratively in atmos.yaml, no shell scripting required.

The official Atmos agent skills are now embedded directly in the Atmos binary. atmos ai skill install <name> works fully offline — no network call, no Git clone — and atmos ai skill list shows a single merged view of every skill available to you alongside what's already installed.

Auth profiles and team defaults are often managed centrally, but workload or app repositories still need to use them. Until now, that usually meant copying profile YAML into each repository and keeping those copies in sync by hand.

Workflows often depend on tools, files, and directories being present before they run. Without a first-class check, those prerequisites tend to hide inside brittle shell snippets and ad hoc command checks.

Terminal demos and recordings are hard to follow when a command dumps hundreds of lines instantly. The output may be correct, but viewers cannot read it and recording tools capture a wall of text instead of a sequence.

Security scanner hooks (Checkov, Trivy, KICS) can now surface findings as inline GitHub annotations on the pull request diff and upload them to GitHub Code Scanning (the Security tab) — natively, with no github/codeql-action step. Custom hooks running any SARIF-emitting tool get the same treatment by adding format: sarif.

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 clones each remote (Git) stack-import source once per run instead of re-cloning it for every import that points at the same repository — and an optional ttl lets a warm cache (like the GitHub Actions cache) skip the clone entirely on subsequent runs.

GitHub Actions has a built-in "Re-run with debug logging" button: when a workflow fails, you click it and the next run launches with runner and step debug logging turned on. Atmos now auto-detects that signal — when you re-run with debug logging, Atmos switches its own log level to Debug for the run. No need to remember to also set ATMOS_LOGS_LEVEL=Debug in your workflow YAML.

atmos describe affected --format=matrix now writes to $GITHUB_OUTPUT automatically when CI is enabled, matching the behavior already shipped for atmos list instances --format=matrix. No more --output-file=$GITHUB_OUTPUT boilerplate in workflow YAML.

Every atmos list subcommand that processes stack manifests now accepts --process-templates and --process-functions (with matching ATMOS_PROCESS_TEMPLATES / ATMOS_PROCESS_FUNCTIONS env vars), matching the flag surface of atmos describe affected and atmos describe stacks. Defaults are true across the board.

When you're using a GitHub App token to manage GitHub resources with Terraform, you probably still want CI commit statuses to use the workflow's own token. Now you can — just set ATMOS_CI_GITHUB_TOKEN.

You can now enable or disable CI PR comments per-pipeline using the ATMOS_CI_COMMENTS_ENABLED environment variable — no config file changes needed.

Atmos stack processing is now up to 3.5× faster for deep-merge operations — the hot path executed thousands of times per atmos describe component, atmos terraform plan, and every other command that reads stack configuration.

The atmos auth console command now supports isolated browser sessions, allowing you to have multiple cloud provider consoles open simultaneously — one per identity — without logout conflicts.

The !terraform.state YAML function now supports reading from S3 buckets encrypted with customer-provided keys (SSE-C).

Atmos helmfile commands now use the identity system for AWS authentication and provide more flexible EKS cluster name configuration.

The !terraform.output YAML function now works seamlessly with Terraform Cloud and Terraform Enterprise backends, enabling cross-component dependencies without switching backend types.

The atmos auth env command now exports AWS_REGION and AWS_DEFAULT_REGION when region is configured in your identity settings.

Atmos toolchain now has native GitHub Actions support with the new github format for atmos toolchain env.

Locals can access {{ .settings }}, {{ .vars }}, and {{ .env }} from the same file during template resolution.

Atmos now supports atmos vendor list and atmos workflow list as aliases for their atmos list vendor and atmos list workflows counterparts.

Atmos now automatically provisions backends during terraform init, eliminating the need for a separate backend create command. When provision.backend.enabled: true is set, backends are created just-in-time during your first Terraform operation.

The source provisioner now provides better visual feedback with spinners during auto-provisioning, interactive confirmation prompts for delete operations, and interactive stack selection when --stack is omitted.

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

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.

atmos auth login now automatically falls back to provider authentication when no identities are configured, enabling seamless first-time login with auto_provision_identities.

Atmos terraform commands now use a modern registry pattern that improves flag validation, provides better help text, and sets the foundation for enhanced developer experience across all terraform subcommands.

Atmos now includes interactive prompts for missing required flags and positional arguments, making commands more discoverable and user-friendly. This feature is being gradually rolled out across commands.

The atmos workflow command now automatically discovers workflow files, eliminating the need to specify --file for uniquely named workflows. This developer experience improvement makes running workflows faster and more intuitive.

Custom commands now support boolean flags with configurable default values. You can define type: bool flags that default to true or false, making it easier to handle special behavior triggers.

This release brings powerful enhancements to color output in CI/CD environments and significant code quality improvements that make Atmos more maintainable and performant.

Atmos help text now automatically adapts to your configured theme, providing a consistent and visually cohesive experience across all commands. Whether you're using a dark theme like Dracula or a light theme like GitHub, help output will match your terminal's color scheme.

Tab completion for the --stack flag is now context-aware, filtering suggestions based on the component you specify.

We've made several quality-of-life improvements to Atmos authentication commands, making identity management smoother and more intuitive.

Atmos auth, documentation, and workflow management commands now work independently of stack configurations, making it easier to use Atmos in CI/CD pipelines and alongside "native" Terraform workflows.

Atmos now detects circular dependencies in YAML function calls and provides a clear call stack showing exactly where the cycle occurs.

Running atmos auth login without specifying an identity is now more user-friendly. When no --identity flag is provided, Atmos presents an interactive selector to choose from your configured identities.

We've significantly improved the AWS SSO authentication experience with styled verification code dialogs, animated status indicators, and proper Ctrl+C handling.