v1.222.0-rc.9

feat(workflows): http step type (webhook alias) with retries Erik Osterman (Cloud Posse) (@osterman) (#2641)

## what

• Add a native http workflow/custom-command step (type: http) that performs an HTTP request — any verb (GET/POST/PUT/PATCH/DELETE/HEAD/OPTIONS), query string parameters, headers, and a request body via body (raw) or form (urlencoded, or JSON when Content-Type is JSON).
• Keep webhook as a first-class alias for http (type: webhook behaves identically) for the fire-a-notification use case. This adds alias support to the step registry: NewBaseHandler is variadic for aliases, Get() resolves aliases, and List/Count report only the canonical entry (no duplicate step type).
• Per-attempt timeout and retry that composes with the existing retry: policy; retry is HTTP-aware (transport errors, 5xx, and 429 retry by default, other 4xx fail fast, and retry.conditions regexes force additional cases).
• Configurable success criteria via expect.status (codes) and expect.response (regexes); the response body and status are captured as the step's value/metadata for downstream steps.
• Schema fields on WorkflowStep and Task (so it works in both workflows and custom commands) plus the HTTPExpect struct, ErrHTTPStep* sentinels, JSON manifest updates, docs, an examples/http-webhooks example, a changelog blog post, and a roadmap milestone.

why

• Calling external endpoints (notify a service, trigger a CI job, hit a deployment webhook, poll a health check) previously required shelling out to curl, which isn't portable (Windows), is awkward to template, and gets no first-class timeout/retry handling.
• The step is a general-purpose, verb-agnostic outbound HTTP client, so http is the accurate name (an inbound callback receiver is what "webhook" conventionally means); webhook is retained as an alias so the evocative name still works.
• Extended/registry step types are not wrapped by the legacy retry.Do path that shell/atmos use, so the handler applies retry itself via retry.WithPredicate — which is what enables status-code-aware retry decisions a generic wrapper can't make.

references

• Docs: workflow step types and custom commands
• Changelog: website/blog/2026-06-20-http-step-type.mdx

Summary by CodeRabbit

Release Notes

• New Features

  • Added an HTTP workflow step (http, with webhook alias) to call HTTP endpoints from workflows.
  • Supports templated URL, method, headers, query, and mutually exclusive raw body vs form payloads.
  • Added response expectations (status allowlist and regex matching), with the response body as the step value and status/headers metadata.
  • Introduced per-step timeouts and HTTP-aware retries, including retry.conditions for additional match-based retries.

• Documentation

  • Expanded HTTP step docs, examples, and retry-condition guidance; updated step type tables.

• Tests

  • Added end-to-end and unit tests covering validation, execution, retries, templating, and aliases.

feat(workflows): add `say` step for audible TTS notifications Erik Osterman (Cloud Posse) (@osterman) (#2640)

## what

• Add a new say workflow step type that speaks its content aloud using text-to-speech, and gracefully degrades to printing the message as a Markdown blockquote when no speech engine is available or when running in CI/headless.
• Introduce a reusable cross-platform pkg/say package (mirroring pkg/browser) that detects macOS say, Linux spd-say/espeak/espeak-ng, and Windows PowerShell System.Speech, behind a Speaker interface with a CommandRunner DI seam and functional options.
• Support a CSS font-family-style voice list (first installed voice on the host wins), a rate field (slow/normal/fast), and a print policy (fallback/always/never); add the matching Voice/Rate/Print fields to WorkflowStep and sentinel errors ErrSayNotFound/ErrVoiceListUnsupported.
• Add an examples/say-something/ reference example, workflow step-type docs, an announcement blog post, and a roadmap milestone under the Workflows Overhaul initiative.

why

• Long-running workflows often outlast your attention; say gives an audible cue when a workflow finishes or needs input, going beyond the bell-only alert step by announcing what happened.
• Shelling out to say only works on macOS — this makes audible notifications portable across macOS/Linux/Windows and safe in CI, so the same workflow runs unchanged everywhere and never fails on a missing engine.

references

• N/A

Summary by CodeRabbit

Release Notes

• New Features

  • Added a say workflow step for cross-platform text-to-speech with automatic engine detection.
  • Supports voice, rate, and a print policy (fallback, always, never) that can render a Markdown blockquote when audio isn’t available.

• Bug Fixes

  • Workflows keep running when speech engines are missing and when voice listing isn’t supported.

• Documentation

  • Added say step docs, a “say something” example (README + Atmos config + workflow), and a blog post; updated step-type listings.

• Tests

  • Added unit tests covering detection, voice enumeration/parsing, argument generation, and say execution.

feat(hooks): CI annotations and SARIF upload for scanner findings Erik Osterman (Cloud Posse) (@osterman) (#2631)

## what

• Surface scanner-hook findings (Checkov, Trivy, KICS) in CI beyond the job summary:
  • ci.annotations (default on) — inline GitHub ::error/::warning annotations anchored at each finding's file and line on the PR diff. The non-Code-Scanning path: needs no GitHub Advanced Security.
  • ci.results (default off) — upload the raw SARIF to GitHub Code Scanning (Security tab) natively, with no github/codeql-action step. Analysis category is auto-derived from the scan target so per-component uploads don't overwrite each other.
• Implemented as native CI provider capabilities (Annotator, SARIFReporter) — siblings of the existing check-run/comment/summary capabilities — not as hooks. All three reporting outputs (ci.summary/ci.annotations/ci.results) are gated by ci.enabled.
• Custom hooks opt in by adding format: sarif to a kind: command hook — any SARIF-emitting tool (tfsec, semgrep, gitleaks, …) gets findings, annotations, and upload with no Go code.
• Docs (incl. required GitHub Actions permissions), a changelog blog post, and a roadmap milestone.

why

• The CI job summary (#2617) gave a readable report, but the two richest GitHub surfaces — inline PR annotations and tracked Code Scanning alerts — were missing even though the data was already in the parsed SARIF.
• Modeling this as provider capabilities (rather than reviving the deprecated ci.* hook kinds) keeps CI reporting where it belongs and lets every SARIF-emitting hook, built-in or custom, participate through one shared path.

references

• Builds on #2617 (scanner findings → CI job summary) and completes the CI-reporting direction from #2614.
• Note: base is main; #2617 is not yet merged, so this PR's diff currently includes #2617's commits — they drop out once #2617 merges and this branch is rebased.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added CI reporting for security scan findings in GitHub Actions: job step summaries, inline workflow diff annotations, and optional GitHub Code Scanning SARIF uploads (configurable via ci.enabled, ci.annotations, and ci.results).
  • Enabled kind: command hooks with format: sarif to route findings into the same CI destinations.
• Bug Fixes
  • Switched the build base image to Debian trixie to resolve scanner runtime GLIBC issues.
  • Standardized AWS custom endpoint configuration to spec.endpoint_url; CI reporting is best-effort and won’t fail scans/plans.
• Documentation
  • Updated CI reporting and hook documentation, plus endpoint configuration references.

feat(container): persistent container component kind + compositions Erik Osterman (Cloud Posse) (@osterman) (#2645)

## what

Adds a stack-scoped, Atmos-native container component kind — one component is one persistent service — plus first-class compositions membership.

• Lifecycle (atmos container <verb> <component> -s <stack>): build, push, pull, run, up, ps, logs, exec, restart, stop, rm, down. Long-running containers are discovered by labels derived from the canonical instance address <stack>/container/<component> (name atmos-<stack>-container-<component>), not local state files. up/run build the image first when vars.build-style build: is set and the image is missing.
• First-class config — image, build, run are top-level component sections (reusing the workflow container-step structs ContainerBuildStep/ContainerRunStep), not nested under vars. Container app env comes from the component env: section.
• atmos container list shows per-instance running state (running/stopped/unknown), discovered by label. The generic atmos list components lists containers as a component type without container-specific status — consistent with terraform/ansible (there is no atmos terraform list/atmos ansible list).
• Compositions — a first-class composition: membership field + a top-level compositions: section (closed for membership, open for fulfillment). Operating a component with undeclared membership is a hard error; atmos composition validate <name> -s <stack> reports fulfilled vs. not-provided services.
• Deep merge — the custom-component fallback now runs metadata.inherits inheritance + generic deep-merge of all top-level keys, so container honors catalog/abstract defaults like built-in kinds. Abstract components are rejected for execution and filtered from listings.
• Extends the describe-component auto-detect and the describe/list type whitelist for container (and fixes the pre-existing ansible gap in list components).

why

Containers should be first-class, addressable component instances like terraform/helmfile/packer/ansible, and atmos list components should show whether each is running. A set of container components grouped by a composition is "our own Compose" with no compose.yaml. Implements docs/prd/container-components.md.

references

• PRD: docs/prd/container-components.md, docs/prd/compositions.md
• Examples: examples/container-component/, examples/compositions/
• Docs: website/docs/cli/commands/container/, website/docs/components/container.mdx
• Contributor skill: .claude/skills/atmos-core-component-development/

[!NOTE]
Stacked on osterman/container-step-prd (the container step), not main. Changelog/roadmap are not required for this base (the gate is main-only); they'll go on the PR that brings the container feature to main.

🤖 Generated with Claude Code

Summary by CodeRabbit

Release Notes

• New Features

  • Added atmos container for persistent, stack-scoped container lifecycle management (build/push/pull, run/up/down, start/stop/restart, rm, ps/logs/exec/attach), including bulk mode (--all) and interactive selection.
  • Added atmos composition validate to report composition service fulfillment across stacks.

• Updates

  • Introduced first-class components.container.* with image/build/run, metadata.inherits deep-merge, and improved run.command parsing.
  • Added run.restart and run.healthcheck support; updated container instance labels to tools.atmos.*, plus enhanced shell completion and log streaming.

• Documentation

  • Updated container/composition guides and added runnable examples.