What's wrong
`cascade-rollback.yaml`'s `deploy-atlas` job calls a deploy callback that declares `image_tag` as `required: true` (the standard "chained automatically by cascade from the build's declared outputs" contract), but only passes `environment`/`sha`:
```yaml
deploy-atlas:
uses: ./.github/workflows/deploy-atlas.yaml
with:
environment: ${{ needs.preflight.outputs.target_env }}
sha: ${{ needs.preflight.outputs.target_sha }}
secrets: inherit
```
This isn't a simple wiring miss like #663: `internal/rollback/command_subcommands.go`'s own doc comment confirms `cascade rollback preflight --gha-output` only ever resolves and writes `target_env`/`target_sha` (plus `target_source`/`can_proceed`) -- there's no image-tag-equivalent output anywhere in the rollback path to wire in, because `cascade-rollback.yaml` has no `build-app`-equivalent job at all (unlike hotfix, which does rebuild).
So for any deploy whose callback depends on a build's output (the documented, standard shape: `depends_on: [app]` auto-forwarding `image_tag`/`artifact_id`), rollback as currently generated has no way to satisfy that callback's required input. It's unclear whether the intended design is:
- rolling back should re-resolve the previously recorded image tag for the target state from manifest state (`ci.state....`), which `preflight` would need to read and output, or
- rollback is only meant to support deploys that don't have a build dependency (in which case the manifest schema or docs should say so, and `lint`/`verify` should probably catch a `rollback`-eligible deploy that has a build dependency it can't resolve), or
- something else I'm not seeing.
How I found it
Adopting cascade in `cfacorp/voice-ordering`, generating orchestrate + hotfix + rollback for the parallel-run phase. `actionlint`'s `workflow-call` check flagged the missing required input; digging into `internal/rollback` confirmed there's no output to wire in, not just a missed one.
Ask
This feels like it needs real design thought rather than a quick patch (unlike #663). Flagging it now so it's tracked; happy to help design/implement once there's a direction.
What's wrong
`cascade-rollback.yaml`'s `deploy-atlas` job calls a deploy callback that declares `image_tag` as `required: true` (the standard "chained automatically by cascade from the build's declared outputs" contract), but only passes `environment`/`sha`:
```yaml
deploy-atlas:
uses: ./.github/workflows/deploy-atlas.yaml
with:
environment: ${{ needs.preflight.outputs.target_env }}
sha: ${{ needs.preflight.outputs.target_sha }}
secrets: inherit
```
This isn't a simple wiring miss like #663: `internal/rollback/command_subcommands.go`'s own doc comment confirms `cascade rollback preflight --gha-output` only ever resolves and writes `target_env`/`target_sha` (plus `target_source`/`can_proceed`) -- there's no image-tag-equivalent output anywhere in the rollback path to wire in, because `cascade-rollback.yaml` has no `build-app`-equivalent job at all (unlike hotfix, which does rebuild).
So for any deploy whose callback depends on a build's output (the documented, standard shape: `depends_on: [app]` auto-forwarding `image_tag`/`artifact_id`), rollback as currently generated has no way to satisfy that callback's required input. It's unclear whether the intended design is:
How I found it
Adopting cascade in `cfacorp/voice-ordering`, generating orchestrate + hotfix + rollback for the parallel-run phase. `actionlint`'s `workflow-call` check flagged the missing required input; digging into `internal/rollback` confirmed there's no output to wire in, not just a missed one.
Ask
This feels like it needs real design thought rather than a quick patch (unlike #663). Flagging it now so it's tracked; happy to help design/implement once there's a direction.