v1.223.1-rc.2

feat(container): Buildx cache and driver config for build steps Erik Osterman (Cloud Posse) (@osterman) (#2771)

## what

• Add driver and cache fields to the native type: container build step (action: build)
• driver selects/creates the Buildx builder instance (docker buildx create), supports a bare-string shorthand (driver: docker-container) or a full form with name, provider, and driver-specific opts (e.g. a mirrored BuildKit image)
• cache (from/to) imports/exports Buildx remote build cache on the plain (non-bake) build path, passed through as --cache-from/--cache-to
• Builder creation is idempotent (a stable default name of atmos, reused so create-if-missing and the builder's own cache persist across runs) and never mutates the ambient default builder — Atmos always selects it explicitly with --builder
• Podman rejects driver the same way it already rejects bake/buildx-only config
• Adds the required blog post and roadmap milestone, and documents driver/cache plus three ways to avoid Docker Hub rate limits in the container step docs

why

• The native container build step had no equivalent to docker/setup-buildx-action's driver-opts or docker/build-push-action's cache-from/cache-to, blocking migration of existing GitHub Actions Docker builds onto native type: container steps
• Remote cache import/export needs a Buildx builder capable of exporting cache (the docker-container driver), and pointing that builder at a mirrored BuildKit image is the cleanest way to avoid Docker Hub rate limits without changing Dockerfiles or host-level daemon config

references

• Related docs: /workflows/steps/type/container#driver, /workflows/steps/type/container#cache

Summary by CodeRabbit

• New Features

  • Added Buildx builder configuration (including named builder selection/creation) via with.driver, supporting both shorthand and detailed driver options.
  • Added Buildx build cache import/export via with.cache with cache.from and cache.to.

• Bug Fixes

  • Podman runtime now fails earlier when a Docker Buildx driver is provided, with a clearer unsupported-driver error.

• Documentation

  • Updated container build step docs with with.driver/with.cache examples and Docker Hub pull-rate mitigation guidance.
  • Added a blog post explaining Buildx cache and driver usage.

docs: deprecate legacy component dependency guidance Erik Osterman (Cloud Posse) (@osterman) (#2773)

## what

• Replace active settings.depends_on examples with canonical dependencies.components syntax across docs, blogs, and public AI examples.
• Move the Spacelift guide into Deprecated, add a native-CI warning, and redirect the former integration URL.
• Reduce the legacy depends_on page to migration guidance and remove active Spacelift promotion.

why

• Prevent new configurations from adopting deprecated dependency syntax or treating the legacy Spacelift integration as a recommended path.

references

• Component Dependencies

Summary by CodeRabbit

• Documentation

  • Updated CLI, migration, and stack/dependency docs to use the dependencies.components format across examples, including component, stack, type, and file/folder dependency listings.
  • Replaced/condensed the legacy settings.depends_on documentation with a dedicated migration guide and clarified common error handling.
  • Refreshed !append YAML documentation to append under dependencies.components.

• Examples / Website

  • Updated example stack manifests to declare inter-component dependencies via dependencies.components.
  • Added a deprecated Spacelift reference and a documentation redirect to the deprecated page.

Improve emulator workflows, Terraform execution, and CI reliability Erik Osterman (Cloud Posse) (@osterman) (#2755)

## Summary

• Make emulator discovery and execution component-aware: scope inventory to configured stack components, restore interactive stack selection, add runtime filtering, and consistently resolve emulator identities, endpoints, and provider settings.
• Add Terraform component mocks across schema, execution, scheduler, and examples; improve component/stack provenance, affected discovery, graph state handling, workspace paths, and Terraform diagnostics.
• Improve secret initialization, container/composition/devcontainer/Helm workflow behavior, and the related CLI help, docs, snapshots, and screengrabs.
• Strengthen cross-platform testing and CI: preserve toolchain paths, make cache locking and cached executables Windows-safe, sanitize runner-specific snapshots, retry transient vendoring and bootstrap downloads, and keep all build artifacts produced through atmos build.
• Refresh examples, PRDs, skills, schemas, website documentation, and generated casts; also update the website websocket dependency for the reported security advisories.

CI reliability fixes

• Vendoring retries transient Git clone failures with bounded exponential backoff.
• The Atmos bootstrap download is retried while the build action continues to invoke atmos build binary for the tested artifact.
• Validation Markdown fixtures follow the repository EditorConfig indentation policy.
• Windows cache-test fixtures create .exe binaries where the toolchain does, preventing a platform-only acceptance failure.

Validation

• go test ./tests -run '^TestCachedTestTool(BinaryNameForOS|BinaryPath|BinaryExists)$' -count=1
• GOOS=windows GOARCH=amd64 go test -c -o build/precondition_cached_tools_windows.test.exe ./tests
• ./build/atmos validate --affected --exclude 'tests/fixtures/**' --exclude '**/*.go' --format rich
• ./build/atmos build binary --target=macos --version=test
• ./build/atmos build version --target=macos

Generate atmos.yaml JSON Schema from code; add `atmos config schema` Erik Osterman (Cloud Posse) (@osterman) (#2761)

## what

• Add a complete JSON Schema for atmos.yaml that is generated from the Go configuration structs (pkg/config/schema, go generate) — Go doc comments become schema descriptions, runtime-only fields are excluded, and YAML function (!include, !env, …), null, and scalar-string-list alternatives are injected so real configs validate.
• Guard the schema so it can never go stale: a drift test regenerates in-process and byte-compares against the committed artifact; ratchet tests force classification of every new AtmosConfiguration field and every new YAML function constant; a corpus test validates all examples/** and demo/** configs plus this repository's own atmos.yaml and .atmos.d (which surfaced and fixed real gaps: map-form env, boolean pager, function-valued polymorphic fields).
• Add atmos config schema [output-path], mirroring atmos stack schema, printing the embedded schema served at atmos://schema/atmos/config/1.0.
• Seed a built-in config entry in the schemas registry so atmos validate schema validates atmos.yaml, atmos.d/**, and project-local profiles out of the box (overridable via schemas.config), add atmos config validate as a shorthand alias for atmos validate schema config, and stop the command from bailing out when no stacks directory exists — schema validation now works in config-only repositories.
• Add atmos stack validate as the symmetric alias for atmos validate stacks, and make pkg/filematch resolve literal (non-glob) patterns with a direct stat instead of walking the entire tree — atmos validate schema in this repository drops from ~6s to ~0.6s, so per-file results stream immediately.
• Wire the schema into the AI/MCP server (new read-only atmos_validate_schema tool alongside atmos_validate_stacks) and the experimental LSP server (line-positioned schema diagnostics for atmos.yaml documents and fragments, with anyOf cascade noise filtered to the most specific violation); pkg/validator gains ValidateYAMLContent for unsaved editor buffers.
• Publish floating (.../atmos-config/1.0/...) and per-release pinned schema copies from the website workflows, and add command docs, a schemas reference section, MCP/LSP doc updates, a changelog post, and a roadmap milestone.

why

• atmos.yaml has grown a larger configuration surface than stack manifests but had no schema at all: typos and mistyped sections were silently ignored by the loader, and editors offered no completion or validation.
• A hand-written schema (like the stack-manifest one) would rot as options ship; generating it from the exact structs Atmos decodes into makes drift impossible, with CI enforcing regeneration.
• Fixes a latent misdefault where atmos validate schema atmos matched atmos.yaml/atmos.yml but validated them against the stack-manifest schema, and a gap where atmos validate schema silently skipped all validation in repositories without a stacks directory.
• Editor integration works with one yaml-language-server modeline (or natively via atmos lsp start), and pinned per-release URLs let teams upgrade the binary without silently absorbing schema changes — the same model the manifest schema adopted in #2749.

references

• closes #2351 — the request for a first-class atmos.yaml JSON Schema
• closes #2731 — supersedes the hand-written schema in that PR (thanks rennokki (@rennokki)!); generating the schema from the config structs means it can never drift from what the CLI actually accepts
• Builds on #2749 (consolidated atmos-manifest schema + per-release pins) and its floating/pinned publishing model
• Changelog: website/blog/2026-07-16-atmos-yaml-schema.mdx; docs: /cli/commands/config/config-schema, /cli/configuration/schemas, /ai/mcp-server, /cli/commands/lsp/start

Summary by CodeRabbit

• New Features
  • Added atmos config schema to print or write the generated atmos.yaml JSON Schema.
  • Added atmos config validate and atmos stack validate, plus built-in schema validation for atmos.yaml/atmos.d//local profile fragments via schemas.config override/disable.
  • Added atmos_validate_schema tool and LSP config-schema diagnostics with accurate line/column reporting.
  • Added native atmos validate ci / atmos ci validate workflow validation (including SARIF/annotations when enabled).
• Documentation
  • Updated CLI, configuration, and blog docs for the new schema/validation commands, tooling, and editor integration.
• Chores
  • Prod/preview deploys now generate schema artifacts and publish/pin versioned snapshots; schema drift is enforced by tests.

feat: implement atmos init and atmos scaffold commands Erik Osterman (Cloud Posse) (@osterman) (#1687)

## what - Implement `atmos init` command for bootstrapping new Atmos projects from built-in templates - Implement `atmos scaffold` command with three subcommands: - `atmos scaffold generate` - Generate code from scaffold templates - `atmos scaffold list` - List available scaffold templates from atmos.yaml - `atmos scaffold validate` - Validate scaffold.yaml configuration files - Refactor code organization to eliminate thin wrappers and improve maintainability: - Rename `pkg/init/` → `pkg/generator/` for clearer, more generic naming - Move `pkg/init/config/` → `pkg/project/config/` for project-level operations - Consolidate template processing into `pkg/generator/engine/` - Move business logic from `internal/exec/` directly into `cmd/` packages - Add comprehensive documentation (PRD, blog post, CLI reference) - Add test coverage for new packages (76.9% for templates, 91.7% for filesystem, 95.7% for merge)

why

• User Experience: Users can now initialize Atmos projects in seconds instead of manually creating configuration files
• Developer Experience: Scaffolding accelerates development by generating boilerplate code from templates
• Code Quality: Refactoring eliminates confusing package names (pkg/init vs init command) and removes unnecessary indirection
• Maintainability: Moving logic into cmd/ packages reduces layers and makes the codebase easier to navigate
• Extensibility: Template-based approach allows users to create custom templates for their organization

references

• Related to initial POC work in experiments/init branch
• Uses command registry pattern from #1643
• Follows established patterns from atmos terraform and atmos describe commands

Summary by CodeRabbit

New Features

• Added atmos init command to initialize Atmos projects from templates with interactive and non-interactive modes
• Added atmos scaffold command suite with generate, list, and validate subcommands for creating code and configuration from templates
• Template support includes variable substitution, dry-run previews, and intelligent file merging for updates

Documentation

• Added comprehensive usage guides, examples, and Product Requirements Documents for template and scaffolding features

🚀 Enhancements

fix(toolchain): fail incomplete parallel installs Erik Osterman (Cloud Posse) (@osterman) (#2769)

## what

• Treat missing terminal results in parallel toolchain installs as failures.
• Add regression coverage for a prematurely closed event channel.

why

• Prevents incomplete parallel installs from reporting a successful command.

references

• Closes #2767

Summary by CodeRabbit

• Bug Fixes
  • Improved batch tool installation reporting when one or more installations do not return a final result.
  • Failed installations are now counted accurately, and the reported error includes the number of failures.
• Tests
  • Added coverage for incomplete batch installation results.

feat(cast): auto-install animated renderers Erik Osterman (Cloud Posse) (@osterman) (#2763)

## what

• Auto-install pinned agg and FFmpeg renderers for animated cast outputs
• Resolve managed binaries to absolute paths while keeping static formats native
• Add renderer coverage and document automatic installation and MP4 palette constraints

why

• Remove the manual renderer setup requirement for GIF and MP4 cast rendering

references

• N/A

Summary by CodeRabbit

• New Features
  • Animated GIF and MP4 rendering now automatically manages and installs the needed tools on first use.
• Bug Fixes
  • Rendering now reports clearer failures and prevents overwriting existing animated outputs.
  • Cached tool discovery on Windows is fixed (improves test/tooling reliability).
  • Terminal-width fallback is more consistent in non-interactive environments by honoring COLUMNS.
• Documentation
  • Updated cast rendering and workflow docs to reflect managed installation and MP4-from-GIF behavior.