Add deploy workflow

[sk593]

Description

Adds the Repo Radius deploy workflow — an auto-generated GitHub Actions workflow that deploys a Radius application against a user's existing AKS/EKS cluster, plus its contract documentation and the radius-deploy skill that drives it.

The workflow stands up an ephemeral k3d Radius control plane on the runner, points it at the user's external target cluster via the chart's targetCluster seam, restores persisted state, runs rad deploy on .radius/app.bicep, then persists state again and tears the ephemeral cluster down.

How the workflow works

1. Authenticate via OIDC — azure/login and/or aws-actions/configure-aws-credentials; no long-lived cloud secrets are stored.
2. Connect to the target cluster — fetches a kubeconfig for the user's AKS/EKS cluster into RADIUS_TARGET_KUBECONFIG (EKS uses a static bearer-token kubeconfig).
3. Stand up the control plane — installs k3d, the rad CLI (edge), and Terraform, then installs Radius with --set global.targetCluster.enabled=true, --set database.enabled=true (durable state), and --set dynamicrp.buildkit.enabled=true (in-pod image builds).
4. Project cloud OIDC tokens into the Radius pods and register the cloud identity with rad credential register.
5. Restore state (rad startup) — restores the control-plane PostgreSQL databases and Terraform recipe-state Secrets from the radius-state git orphan branch (no-op on first run).
6. Register resource types + recipe pack — clones resource-types-contrib, registers Radius.Compute/containerImages, and creates the environment with a provider-specific Terraform recipe pack.
7. Deploy the application — runs rad deploy .radius/app.bicep with the image parameter (defaults to the commit SHA) and the optional password parameter from RADIUS_DB_PASSWORD.
8. Persist state (rad shutdown, if: always()) — backs the databases and Terraform state up to the radius-state branch even on failure.
9. Tear down — deletes the ephemeral radius-cp cluster; on failure, logs are uploaded as the radius-logs artifact.

Type of change

• This pull request fixes a bug in Radius and has an approved issue (issue link required).
• This pull request adds or changes features of Radius and has an approved issue (issue link required).
• This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional).
• This pull request is a design document and only includes files in the eng/design-notes directory.

Fixes: #12118

Contributor checklist

Please verify that the PR meets the following requirements, where applicable:

• An overview of proposed schema changes is included in a linked GitHub issue.
  • Yes
  • Not applicable
• A design document is added or updated under eng/design-notes/ in this repository, if new APIs are being introduced.
  • Yes
  • Not applicable
• The design document has been reviewed and approved by Radius maintainers/approvers.
  • Yes
  • Not applicable
• A PR for resource-types-contrib is created, if resource types or recipes are affected by the changes in this PR.
  • Yes
  • Not applicable
• A PR for dashboard is created, if the Radius Dashboard is affected by the changes in this PR.
  • Yes
  • Not applicable
• A PR for the documentation repository is created, if the changes in this PR affect the documentation or any user facing updates are made.
  • Yes
  • Not applicable

[github-actions]

Dependency Review

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

OpenSSF Scorecard

Package	Version	Score	Details
actions/actions/checkout	df4cb1c069e1874edd31b4311f1884172cec0e10	🟢 6.9	Details Check Score Reason Code-Review 🟢 10 all changesets reviewed Maintained 🟢 10 16 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 10 Binary-Artifacts 🟢 10 no binaries found in the repo Dangerous-Workflow 🟢 10 no dangerous workflow patterns detected CII-Best-Practices ⚠️ 0 no effort to earn an OpenSSF best practices badge detected Token-Permissions ⚠️ 0 detected GitHub workflow tokens with excessive permissions Fuzzing ⚠️ 0 project is not fuzzed License 🟢 10 license file detected Packaging ⚠️ -1 packaging workflow not detected Pinned-Dependencies ⚠️ 3 dependency not pinned by hash detected -- score normalized to 3 Signed-Releases ⚠️ -1 no releases found Security-Policy 🟢 9 security policy file detected Branch-Protection 🟢 5 branch protection is not maximal on development and all release branches SAST 🟢 10 SAST tool is run on all commits

Scanned Files

• .github/workflows/functional-test-noncloud.yaml

[github-actions]

Unit Tests

    2 files  ± 0    452 suites  +2   7m 30s ⏱️ -4s
5 656 tests +65  5 654 ✅ +65  2 💤 ±0  0 ❌ ±0 
6 853 runs  +65  6 851 ✅ +65  2 💤 ±0  0 ❌ ±0 

Results for commit cd8fec5. ± Comparison against base commit 62b741f.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.98%. Comparing base (62b741f) to head (cd8fec5).
⚠️ Report is 15 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12250      +/-   ##
==========================================
+ Coverage   52.87%   52.98%   +0.10%     
==========================================
  Files         751      754       +3     
  Lines       48353    48686     +333     
==========================================
+ Hits        25566    25795     +229     
- Misses      20387    20467      +80     
- Partials     2400     2424      +24     

☔ 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.

[sylvainsf]

Review: PR #12250 — Add deploy workflow

Reviewer: @sylvainsf · Against: Repo Radius feature spec (#12078, Investments 3 & 4) and issue #12118

Summary

Strong real-world deploy workflow — the recipe-pack/environment model, the
container-image build path, and the OIDC credential handling are more complete
than the earlier draft, and it absorbed the full end-to-end statestore test
(install → deploy → rad shutdown → teardown → reinstall → rad startup →
cross-deploy) and its CI leg unchanged. The main concern is drift from the
standardized Investment 3 contract: this is a deploy-only workflow, not the
general radius_commands engine the spec defines, and it’s missing the
per-command output artifacts and a design note. One hardcoded personal ref must
change before merge.

What’s good (keep as-is)

• Recipe pack + Radius.Core/environments generated and deployed, with
  provider-gated recipes (AWS RDS vs Azure Flexible Server). This is the shape
  ongoing projects need.
• Container image build path — dynamicrp.buildkit.enabled=true, oras,
  traefik disabled, in-pod BuildKit + GHCR push secret, containerImages recipe
  and local Bicep extension.
• Credential model — rad credential register aws irsa / azure wi plus
  projected OIDC token files. For AWS this is more faithful to the real code path
  (UCP AWS proxy + Terraform provider read the IRSA token file) than env-var
  injection. Prefer this approach.
• radius-deploy skill and SHA-pinned actions.

Blocking

1. Hardcoded personal recipe ref

.github/extension/radius-deploy.yml (Azure mySQL recipe, ~line 410):

source: 'git::$REPO//Data/mySqlDatabases/recipes/azure/terraform?ref=sk593/add-azure-mysql-recipe'

Pinned to a personal in-flight branch — it will break once that branch
moves/merges. Replace with the stable ref ($REF / main) before merge.

Spec gaps (Investment 3 contract)

2. Dispatch contract: image instead of radius_commands

The spec (Step 3, Investment 3) defines the inputs as environment +
radius_commands — a single command string or a JSON array, executed in
order, stopping on first failure. This workflow exposes environment + image
and hardcodes rad deploy .radius/app.bicep, so it’s deploy-only: app graph
and multi-command flows can’t be expressed, and frontends can’t drive arbitrary
rad commands through the documented seam.

3. No per-command output artifacts

Spec Step 5 / Investment 3 require each command’s output to be uploaded as an
artifact so a frontend can poll results incrementally. This workflow only
uploads radius-logs on failure — there’s no success-path radius-output.

4. No eng/design-note

Nicole has asked for a technical design note for this feature. The PR ships the
skill + README but no durable design doc under
eng/design-notes/environments/. (One was drafted for the earlier workflow PR
and can be ported.)

Non-blocking / review-worthy

• Mutates the user’s source in place — sed -i injects
  extension radiusCompute into .radius/app.bicep. Side-effecting on a
  user-owned file during deploy is surprising; consider working on a copy or
  guarding it.
• Demo-specific cruft — log collection hardcodes default-todo-list-app and
  the dbsecret name. Harmless but worth genericizing.
• rad credential register reintroduced — deliberately, and I think
  correctly for the IRSA/WI token-file model, but note it diverges from spec note
  SN29 (“no need for rad credential commands”). Worth a one-line rationale in
  the README so the divergence is intentional and documented.

Recommendation

1. Keep this PR’s credential model, recipe pack, image-build path, and skill.
2. Add the radius_commands dispatch contract (single-string-or-JSON-array,
   ordered, stop-on-first-failure) + per-command radius-output artifact.
3. Add the eng/design-note (required by Nicole).
4. Replace the sk593/add-azure-mysql-recipe ref.
5. Test + CI leg are already settled (identical to the earlier draft) — no action.

Note: gaps #2 (the radius_commands contract, added alongside image so
the default deploy is unchanged), #3 (per-command radius-output artifact), and
#4 (the design note) are addressed in #12264, opened against this branch.
#1 (the hardcoded recipe ref) and the non-blocking items are left for you.

[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	cd8fec5
Unique ID	funcd1d13d29ca
Image tag	pr-funcd1d13d29ca

• 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-funcd1d13d29ca
• 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-funcd1d13d29ca
• dynamic-rp test image location: ghcr.io/radius-project/dev/dynamic-rp:pr-funcd1d13d29ca
• controller test image location: ghcr.io/radius-project/dev/controller:pr-funcd1d13d29ca
• ucp test image location: ghcr.io/radius-project/dev/ucpd:pr-funcd1d13d29ca
• 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