Publish deploy status as a workflow artifact

[brooke-hamilton]

NOTE: This changes the radius repo side of a cross-repo contract with the ai-extensions repo. The canvas reader in radius-project/ai-extensions still expects the old GHCR transport, so merging this alone leaves the Deployed tab empty until the matching reader change lands. See Merge ordering below.

Description

Publishes deploy status as a GitHub Actions workflow artifact instead of an OCI artifact in GHCR, and adds an automated test for the publish-deploy-status action.

The canvas needs deployment state it can read while a deploy is running. GHCR can't provide that — the artifact is pushed once, at the end. Workflow artifacts can: GET /repos/{o}/{r}/actions/runs/{run_id}/artifacts is readable mid-run, and GET /repos/{o}/{r}/actions/artifacts?name=<name> returns newest-first repo-wide so a fresh canvas session finds the last deploy without knowing a run id.

Scope

Ships: correct deploy status after every deploy, including failed ones; the deploy-progress.json contract; the test.

Does not ship: live per-resource progress. This step runs after rad deploy returns, and actions/upload-artifact is a uses: step, so a composite step cannot invoke it mid-execution. A background poller inside the deploy step would have to write directly to the artifact REST service using ACTIONS_RUNTIME_TOKEN/ACTIONS_RESULTS_URL. That's follow-up work.

sequence is in the contract for that work and is always 1 today, since there is exactly one upload per run — the consumer's merge logic won't need to change when mid-run uploads land. state: in_progress is not a placeholder: it is reachable today, with the "no verdict" meaning described under What changed rather than as a live-progress signal.

What gets published

One artifact named radius-deploy-status-<environment>-<app> (lowercased, characters outside [a-z0-9._-] collapsed to -), retained 30 days, containing five files:

File	Contents
deploy-graph.json	rad app graph output — what the Deployed tab renders
deploy-progress.json	Per-resource status. New in this PR, replaces the TSV deploy-progress.log. The authority on deploy state, and the only status file the canvas reads
deploy-activity.log	The rad command result envelope (outcome, exit code)
deploy-controlplane.log	rad version and rad env list at publish time
deploy-state.txt	Flat key=value run summary. Predates this work; not read by the canvas

What changed

1. Transport: GHCR → workflow artifacts (publish-deploy-status/action.yml)

oras push is replaced by actions/upload-artifact. This removes three problems rather than working around them:

• No packages: write needed, so the pre-flight check that validated a different package than the one written to no longer matters.
• The registry/tag derivation hand-duplicated in bash here and in TypeScript in the canvas — the source of an earlier invalid-tag bug — is gone.
• RADIUS_GRAPH_TAG is removed. RADIUS_GRAPH_REGISTRY is kept: despite the similar name it is read by the rad CLI itself (cmd/rad/cmd/root.go:262) to select the modeled graph archive backend, and removing it would break rad startup. With deploy status no longer using it, that variable has exactly one meaning again.

2. deploy-progress.json

schemaVersion, application, environment, runId, sequence, updatedAt, state, and resources[]. Each resource carries both the raw provisioningState and a normalized status: the producer owns the mapping because it knows the Radius version, while emitting the raw value lets the consumer recover if that mapping goes stale.

Two normalization rules matter to the reader:

• An unrecognized provisioning state normalizes to in_progress, never failed. A Radius state this action hasn't seen must not paint a node red.
• Run-level state is succeeded/failed/in_progress, where in_progress also means no verdict — it is what a finished run reports when rad-commands-result.json is missing or unreadable. Reporting a failure the deploy may not have had is worse than reporting no outcome. This is reachable today, not only once mid-run uploads exist.

3. Publishing is best-effort and never fails a deploy

Every path exits 0. Which paths publish differs, and the distinction matters to anyone debugging an empty tab:

• Application name unresolvable, or rad app graph fails → warn, publish nothing, published=false.
• rad resource list fails → still publishes, with run-level state and an empty resources array. The tab shows the run rather than nothing.

4. Structural changes to support the above

The action is now two composite steps: generate (writes files, sets outputs) and a uses: upload gated on steps.generate.outputs.published == 'true'. STATUS_DIR is a deterministic ${RUNNER_TEMP:-/tmp}/radius-deploy-status rather than mktemp -d, because the upload step must reference the path; the :- fallback is also what makes the step runnable outside a runner, and therefore testable. rad app graph stderr goes to a temp file outside STATUS_DIR, since the whole directory ships in the artifact. Step outputs are emitted exactly once per exit path rather than written up front and overwritten — duplicate keys in $GITHUB_OUTPUT make the winning value an implementation detail, and guessing wrong fails silently in both directions.

Tests

Adds a unit test for the action. It stubs rad, points RUNNER_TEMP/GITHUB_OUTPUT at a temp sandbox, and asserts on the files and step outputs the action produces. It executes the real run: block extracted from action.yml rather than a copy, so it cannot drift from the action. No Docker, network, registry, cluster, credentials, or rad binary; runs in a couple of seconds.

make test-publish-deploy-status   # this script only; needs bash, jq, python3
make test                         # also runs it, with the Go unit tests

In CI it runs on every pull request to main through the existing Unit Tests workflow → make test, and a failure surfaces as a failed Run Unit Tests check. Same pattern as deploy-parameters_test.sh in run-rad-commands/.

Each of the 11 guarded behaviours was individually reverted in action.yml and the test confirmed to fail before the action was restored. Three of those controls guard the cross-repo interface: a renamed resources[] field, an unknown state normalizing to failed, and a bumped schemaVersion. shellcheck -s bash is clean.

The transport itself was exercised separately in a throwaway repo running the real actions/upload-artifact: an artifact was readable over the REST API while the run was still in progress, an environment named My Env/Prod produced a name GitHub accepted, both consumer lookups worked, and deploy-progress.json survived upload and download unchanged.

Merge ordering

This must land close to the matching ai-extensions change. The canvas reader currently pulls from GHCR; once this merges, the producer stops writing there. The reader change (workflow-artifact transport, removal of the dead radius-deploy-status orphan-branch reads) is in progress on brooke-hamilton-deployed-graph-artifacts.

Known gaps

• Nothing involving rad has been verified end to end. No real deploy has run, so rad app graph and rad resource list output shapes remain assumed, and a real failed deploy has never produced a payload. That is the remaining risk and it is confined to the rad interaction. If rad's output surprises us, the action warns and skips publishing rather than failing the deploy, so the worst case is an empty Deployed tab — today's behaviour, not a regression.
• The non-ASCII sanitization control doesn't reproduce under C.UTF-8, so the test selects a full UTF-8 locale from locale -a and prints a note: line if none exists. If that note appears in CI, only the static LC_ALL=C guard is live. ubuntu-24.04 has en_US.utf8, so it shouldn't.
• deploy-progress.json is asserted producer-side only. A one-sided change in the consumer still fails silently; a fixture-based test in ai-extensions would close the loop, and the fixture has been handed over.
• deploy-state.txt reports state=success while deploy-progress.json reports "state": "succeeded" — two vocabularies in one artifact. deploy-state.txt predates this work and something may parse its current values, so it is left alone deliberately. Documented in README step 14.

File change summary

File	Change
.github/extension/actions/publish-deploy-status/action.yml	Artifact transport, deploy-progress.json, two-step structure, deterministic STATUS_DIR, single-write step outputs
.github/extension/actions/publish-deploy-status/publish-deploy-status_test.sh	New — unit test for the action, run by make test in CI
build/test.mk	New test-publish-deploy-status target, added to test: prerequisites
.github/extension/run-rad-commands-azure.yml	Drop RADIUS_GRAPH_TAG
.github/extension/run-rad-commands-aws.yml	Drop RADIUS_GRAPH_TAG
.github/extension/README.md	Document the artifact transport, payload, and status file semantics

[Copilot]

Pull request overview

This PR changes the deploy-status producer used by the GitHub Actions “run-rad-commands” workflows: it switches transport from GHCR/OCI to GitHub Actions workflow artifacts and introduces a CI-enforced unit test harness to keep the cross-repo deploy-status contract stable.

Changes:

• Update publish-deploy-status to generate deploy-progress.json and upload the status bundle via actions/upload-artifact under a deterministic artifact name.
• Add a bash-based unit test harness for the composite action and wire it into make test via a new test-publish-deploy-status target.
• Remove RADIUS_GRAPH_TAG from the provider workflows and update extension documentation to describe the new transport.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
.github/extension/actions/publish-deploy-status/action.yml	Switch deploy-status publishing to workflow artifacts; generate deploy-progress.json; emit step outputs for upload gating.
.github/extension/actions/publish-deploy-status/publish-deploy-status_test.sh	Add unit test harness that executes the action’s real run: block and asserts the interface/behavior.
build/test.mk	Add test-publish-deploy-status target and include it in the main test prerequisite list.
.github/extension/run-rad-commands-azure.yml	Stop passing RADIUS_GRAPH_TAG into the workflow environment.
.github/extension/run-rad-commands-aws.yml	Stop passing RADIUS_GRAPH_TAG into the workflow environment.
.github/extension/README.md	Document workflow-artifact transport and update environment-variable guidance.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.github/extension/actions/publish-deploy-status/action.yml:98

• The mktemp file used to capture rad app graph stderr is never removed. On a long-lived/self-hosted runner this can leak temp files over time. Remove the file after printing it (both success and failure paths).

        GRAPH_STDERR=$(mktemp)
        if ! rad app graph --application "$APP_NAME" --preview --include-icons --output json > "$STATUS_DIR/deploy-graph.json" 2> "$GRAPH_STDERR"; then
          echo "::warning::Failed to generate deployed graph; skipping publish."
          cat "$GRAPH_STDERR" || true
          emit_outputs "" false

.github/extension/actions/publish-deploy-status/action.yml:177

• --argjson resources "$RESOURCES_JSON" embeds the full resources payload into the jq command line. For apps with many resources this can hit OS argv length limits and make jq fail, which would fail the whole step under set -e (turning a reporting concern into a deploy failure). Pass the JSON via a file/stream instead (e.g., jq --slurpfile).

        jq -n \
          --argjson resources "$RESOURCES_JSON" \
          --arg application "$APP_NAME" \
          --arg environment "$ENVIRONMENT" \
          --argjson runId "${GITHUB_RUN_ID:-0}" \

[github-actions]

Unit Tests

    2 files  ±0    457 suites  ±0   7m 26s ⏱️ -1s
6 208 tests ±0  6 206 ✅ ±0  2 💤 ±0  0 ❌ ±0 
7 437 runs  ±0  7 435 ✅ ±0  2 💤 ±0  0 ❌ ±0 

Results for commit a05f344. ± Comparison against base commit 89f7c62.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.github/extension/actions/publish-deploy-status/action.yml:177

• The action is intended to be best-effort reporting (warn + exit 0 on failures), but the unguarded jq -n ... > deploy-progress.json will terminate the step under set -e if jq is missing or errors, which can fail an otherwise successful deployment. Wrap this write in a failure check that emits published=false and exits 0.

        jq -n \
          --argjson resources "$RESOURCES_JSON" \
          --arg application "$APP_NAME" \
          --arg environment "$ENVIRONMENT" \
          --argjson runId "${GITHUB_RUN_ID:-0}" \

.github/extension/actions/publish-deploy-status/publish-deploy-status_test.sh:200

• sed -i -E is GNU-sed specific and will fail on BSD sed (common on macOS), which conflicts with the goal of running this test on a developer machine. Use a portable -i form (backup suffix) and delete the backup file.

    sed -i -E "s|^RESULT_FILE=.*|RESULT_FILE=${RESULT_FILE}|" "${BODY_SCRIPT}"

[github-actions]

Functional Tests - statestore-noncloud

2 tests  ±0   2 ✅ ±0   3m 6s ⏱️ -41s
1 suites ±0   0 💤 ±0 
1 files   ±0   0 ❌ ±0 

Results for commit 9af9bde. ± Comparison against base commit f54a662.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.18%. Comparing base (89f7c62) to head (a05f344).

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12628      +/-   ##
==========================================
- Coverage   54.18%   54.18%   -0.01%     
==========================================
  Files         770      770              
  Lines       51061    51061              
==========================================
- Hits        27668    27666       -2     
- Misses      20789    20790       +1     
- Partials     2604     2605       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.github/extension/actions/publish-deploy-status/action.yml:158

• The jq mapping can error if .properties.status is not an object (GenericResource properties is untyped), which would cause the whole resource normalization to fall back to an empty resources array. Use jq’s optional operator so a non-object status doesn’t break the entire payload.

                message: (.properties.status.message // "")

.github/extension/actions/publish-deploy-status/action.yml:95

• GRAPH_STDERR is created with mktemp but never removed. Even though it’s outside STATUS_DIR (so it won’t be uploaded), it will leak a temp file on every run; add a trap to clean it up on all exit paths.

        GRAPH_STDERR=$(mktemp)
        if ! rad app graph --application "$APP_NAME" --preview --include-icons --output json > "$STATUS_DIR/deploy-graph.json" 2> "$GRAPH_STDERR"; then

[github-actions]

Functional Tests - corerp-cloud

30 tests  ±0   29 ✅ ±0   19m 47s ⏱️ +25s
 2 suites ±0    1 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit a05f344. ± Comparison against base commit 89f7c62.

♻️ This comment has been updated with latest results.

[radius-functional-tests]

Radius functional test overview

🔍 Go to test action run

Click here to see the test run details

Name	Value
Repository	radius-project/radius
Commit ref	a05f344
Unique ID	func4f6a1a9e19
Image tag	pr-func4f6a1a9e19

• Dapr: 1.14.4
• Azure KeyVault CSI driver: 1.4.2
• Azure Workload identity webhook: 1.3.0
• Bicep recipe location ghcr.io/radius-project/dev/test/testrecipes/test-bicep-recipes/<name>:pr-func4f6a1a9e19
• Terraform recipe location http://tf-module-server.radius-test-tf-module-server.svc.cluster.local/<name>.zip (in cluster)
• applications-rp test image location: ghcr.io/radius-project/dev/applications-rp:pr-func4f6a1a9e19
• dynamic-rp test image location: ghcr.io/radius-project/dev/dynamic-rp:pr-func4f6a1a9e19
• controller test image location: ghcr.io/radius-project/dev/controller:pr-func4f6a1a9e19
• ucp test image location: ghcr.io/radius-project/dev/ucpd:pr-func4f6a1a9e19
• deployment-engine test image location: ghcr.io/radius-project/deployment-engine:latest

Test Status

⌛ Building Radius and pushing container images for functional tests...
✅ Container images build succeeded
⌛ Publishing Bicep Recipes for functional tests...
✅ Recipe publishing succeeded
⌛ Starting corerp-cloud functional tests...
⌛ Starting ucp-cloud functional tests...
✅ ucp-cloud functional tests succeeded
✅ corerp-cloud functional tests succeeded