fix(workflows): resolve step vars in inline shell/atmos/exec steps - #2711
Conversation
|
Tip Atmos Pro
No affected stacks workflow was detected for this pull request. 
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (5)
📝 WalkthroughWalkthroughAdds workflow step templating for inline ChangesWorkflow step templating
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
…/exec commands and env
Workflow step types handled inline (shell, atmos, exec) ran their raw
command and merged their env: values without passing either through the
step-variable template engine, so {{ .steps.*.value }} / {{ .env.* }} /
{{ .flags.* }} were emitted literally. Handler-routed step types and custom
command steps already resolve these; workflows were the outlier, breaking the
documented 'use step outputs in subsequent steps' contract.
ExecuteWorkflow now resolves inline step commands and env: values through the
same template engine custom command steps use (full Atmos renderer with
Sprig/Gomplate + multi-pass), so behavior is identical in both. A new
Variables.ResolveWith applies a per-call env overlay without mutating the
shared executor env, avoiding cross-step env leakage.
04eb9ff to
526a376
Compare
|
CodeRabbit (@coderabbitai) is |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
rg -n '\.steps\.' --type=go -C2 | head -100
echo "---outputs---"
rg -n 'steps\[.*\]\.Outputs|StepResult|\.values\b|\.outputs\b' --type=go -C2 pkg/runner/step | head -100
echo "---mdx---"
rg -n 'steps\.' website/docs/workflows -C2
echo "---variables.go outline---"
fd variables.go pkg/runner/step
ast-grep outline pkg/runner/step/variables.go --items all
</br>
</br>
</br>
</br>
</br>Length of output: 534 🏁 Script executed: #!/bin/bash
fd variables.go pkg/runner/step
echo "---"
cat pkg/runner/step/variables.go
echo "---struct with steps---"
rg -n '"steps"|steps\[' --type=go -C3 pkg/runner
echo "---mdx file---"
fd index.mdx website/docs/workflows/workflows/workflow/steps
cat website/docs/workflows/workflows/workflow/steps/index.mdx | sed -n '1,200p'
</br>Length of output: 25122
So for the new doc section ("Referencing values from other steps"), |
Erik Osterman (Cloud Posse) (osterman)
added
the
patch
33d1a0d
into
cloudposse:main
|
Tip Atmos Pro
No affected stacks workflow was detected for this pull request.
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2711 +/- ##
=======================================
Coverage 81.19% 81.20%
=======================================
Files 1632 1633 +1
Lines 154292 154360 +68
=======================================
+ Hits 125279 125343 +64
- Misses 22091 22094 +3
- Partials 6922 6923 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
These changes were released in v1.223.0-rc.7. |
3 participants
What
Workflow step types handled inline (
shell,atmos,exec) now resolve step-variable templates —{{ .steps.*.value }},{{ .env.* }},{{ .flags.* }}, plus Sprig/Gomplate functions — in both the step command and the stepenv:values, matching how custom command steps already behave.Before this change,
terraform apply {{ .steps.component.value }} -auto-approvewas passed through verbatim (literal{{ .steps.component.value }}); now it resolves toterraform apply vpc -auto-approve.Why
This is a bug, not a new feature. The documented contract (PRD goal “capture step outputs for use in subsequent steps via Go templates”, and its own examples using
type: atmos/type: shellcommand steps) is that any step can consume prior steps' outputs. Handler-routed step types (toast,markdown,container, the interactive prompts, …) and custom command steps already resolved these templates; workflowshell/atmos/execsteps were the outlier — they executed the rawcommandand mergedenv:values without running either through the step-variable engine, so the templates were emitted literally. It went unnoticed because the shipped examples only surface step values through handler-routed display steps, never a rawshell/atmoscommand.How
ExecuteWorkflowconfigures the workflow step executor with the same template engine as the custom command executor (cmd/cmd_utils.go): the full Atmos renderer (Sprig/Gomplate), multi-pass rendering, and flag protection — so templating behaves identically in workflows and custom commands.env:values are resolved through that engine before execution.Variables.ResolveWithapplies a per-call environment overlay without mutating the shared executor env, so a step's environment is visible as{{ .env.* }}without leaking across steps.prepareStepEnvironmentstays a pure merger (its existing tests are unchanged); env values are resolved ahead of it.Commands and
env:values without template markers are returned unchanged.Testing
Variables.ResolveWith(overlay + non-mutation), command resolution (.steps+ env overlay, non-leak, Sprig parity, invalid-template error), andenv:resolution.shellstep's command,env:, and a Sprig function all resolve correctly.go build ./...,pkg/runner/step+internal/execsuites, andatmos lint changedare clean.References
docs/fixes/2026-07-07-workflow-step-variable-templating.mdcmd/cmd_utils.go(custom command step executor)