59 posts tagged with "Enhancement"

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.

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.