Pass RADIUS_STATE_* vars to rad startup/shutdown in deploy workflows#12472
Conversation
Deploys dispatched via the Radius canvas extension failed in the Restore Radius state step with 'OCI archive repository is not configured; set RADIUS_STATE_REGISTRY or RADIUS_GRAPH_REGISTRY'. The extension sets RADIUS_STATE_BACKEND / RADIUS_STATE_REGISTRY / RADIUS_STATE_ARCHIVE as environment-scoped GitHub variables on the target environment, but the deploy workflows never mapped them into the process environment, so rad startup (restore-state) and rad shutdown (teardown) never saw them. Add a job-level env: block to run-rad-commands-azure.yml and run-rad-commands-aws.yml exposing the three RADIUS_STATE_* vars. They're set at job level (not workflow level) so environment-scoped vars.* resolve, and are inherited by every step including the shared restore-state/teardown composite actions. Fixes #12471 Signed-off-by: sk593 <shruthikumar@microsoft.com>
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Radius functional test overviewClick here to see the test run details
Test Status⌛ Building Radius and pushing container images for functional tests... |
There was a problem hiding this comment.
Pull request overview
This PR fixes GitHub Actions deploy failures triggered by the Radius canvas extension by ensuring environment-scoped RADIUS_STATE_* GitHub Environment variables are surfaced into the job process environment so the shared restore-state (rad startup) and teardown (rad shutdown) composite actions can access the OCI state archive configuration.
Changes:
- Add job-level
env:mappings forRADIUS_STATE_BACKEND,RADIUS_STATE_REGISTRY, andRADIUS_STATE_ARCHIVEin the Azure deploy workflow template. - Add the same job-level
env:mappings in the AWS deploy workflow template.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| .github/extension/run-rad-commands-azure.yml | Exposes environment-scoped RADIUS_STATE_* variables at the deploy job level so rad startup/shutdown can open the OCI state archive. |
| .github/extension/run-rad-commands-aws.yml | Mirrors the Azure workflow fix for AWS so state restore/persist works consistently across templates. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #12472 +/- ##
==========================================
- Coverage 53.42% 53.41% -0.02%
==========================================
Files 762 762
Lines 50246 50246
==========================================
- Hits 26843 26837 -6
- Misses 20879 20882 +3
- Partials 2524 2527 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Description
Deploys dispatched through the Radius canvas extension fail in the Restore Radius state step with:
Root cause
The canvas extension provisions the OCI state package and sets these environment-scoped GitHub variables on the target GitHub Environment at environment-creation time:
RADIUS_STATE_BACKEND(e.g.oci)RADIUS_STATE_REGISTRY(e.g.ghcr.io/<owner>/<repo>-radius-state-<env>-<hash>)RADIUS_STATE_ARCHIVE(e.g.radius-state)But the deploy workflow templates never map these into the process environment, so
rad startup(sharedrestore-stateaction) andrad shutdown(sharedteardownaction) never see them.run-rad-commands-azure.yml/run-rad-commands-aws.ymlonly exposeENVIRONMENT,APP_FILE,APP_IMAGE, and recipe-pack vars.Fix
Add a job-level
env:block to thedeployjob in bothrun-rad-commands-azure.ymlandrun-rad-commands-aws.ymlexposing the threeRADIUS_STATE_*vars.Job level is deliberate: environment-scoped
vars.*only resolve within a job that declaresenvironment:, and a job-levelenv:is inherited by every step — including the sharedrestore-state/teardowncomposite actions whererad startup/rad shutdownrun, plus the deploy/app-graph commands.Type of change
Fixes #12471