Repository navigation
Add radius_commands dispatch contract + deploy-workflow design note - #12264
Merged
Merged
Conversation
Adds the Investment 3 dispatch contract and the technical design note the Repo Radius feature requires, on top of the deploy workflow. - radius-deploy.yml: add an optional 'radius_commands' workflow_dispatch input alongside 'image'. A single rad command string or a JSON array (rad prefix omitted) runs in order, stops on first failure, and uploads each command's output as the radius-output artifact for incremental frontend polling. When empty, the workflow runs its existing default 'rad deploy' of .radius/app.bicep, so current behavior is unchanged. - eng/design-notes: add the deploy-workflow technical design (Investments 3 & 4), documenting the dispatch contract, the RADIUS_TARGET_KUBECONFIG seam, the UCP credential + projected-OIDC-token model, state persistence, and the recipe pack. Related: #12118 Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com>
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
sylvainsf
marked this pull request as ready for review
June 26, 2026 01:58
Contributor
There was a problem hiding this comment.
Pull request overview
This PR extends the Repo Radius deploy workflow template by formalizing the radius_commands dispatch contract (to support running one or more arbitrary rad commands) and adds a technical design note documenting the end-to-end deploy workflow design and its integration seams.
Changes:
- Add optional
radius_commandsworkflow_dispatch input to run either a singleradcommand string or a JSON array of commands, capturing output for artifact upload. - Capture command output into
/tmp/radius-outputand upload it as aradius-outputartifact (plus update default deploy logging to tee into the same output directory). - Add
eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.mddescribing Investments 3/4, workflow stages, and contracts.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
.github/extension/radius-deploy.yml |
Adds radius_commands input and a command-execution path that captures stdout/stderr and uploads radius-output. |
eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md |
Adds a design note documenting the workflow’s dispatch contract, kubeconfig seam, credential model, and state persistence. |
sk593
reviewed
Jun 26, 2026
- radius-deploy.yml: add `set -o pipefail` and guard the default `rad deploy` so a failed command piped through `tee` fails the step (the loop already used `if ! ... | tee`; pipefail makes that correct too). Clarify in the `radius_commands` input description and comments that commands run verbatim, so callers must include `--environment` and any `--parameters` (image, password). Note the DB-password env export is only auto-applied on the default deploy path. - design note: unwrap hard-wrapped prose to single lines per the repo Markdown convention (MD013 disabled). Correct the Outputs section — the `radius-output` artifact uploads once after the command stage, not incrementally; true per-command upload is called out as a planned enhancement. Related: #12118 Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com>
Capture two backend decisions in the deploy-workflow technical design, grounded in the Repo Radius feature spec's Investments 1 and 5: - Cluster credential model: document v1 injected-kubeconfig (shipping today) vs the v2 cloud-derived model (eksClusterName/aksClusterName, in-process credential acquisition) the spec's Investment 1 points at, and why v2 is the better backend for this workflow (it removes the EKS 15-minute token-refresh dance). The action contract hides which model is used, so v1 is a sanctioned interim. - Control plane startup (Investment 5): package the engine as a composite (not Docker) action and pre-bake the k3d control-plane image so install is a local image reference rather than a registry pull. Related: #12118 Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com>
Update the dispatch contract to match the latest Repo Radius spec direction: - Rename the input `radius_commands` -> `rad_commands` (and the step to "Run rad commands"). - Replace the per-command `radius-output` files with a single combined `rad-commands-result` JSON artifact: a top-level outcome/exitCode plus a `commands` array (index, command, outcome, exitCode, output) in input order. A trap finalizes the artifact on exit so a failed or disallowed run still yields a complete result. - Add allowed-command validation: each command's leading verb is checked against an allow-list before any command runs, so commands outside the ephemeral per-run model fail fast (outcome: disallowed_command, exit 2) without provisioning anything. - The default deploy path and the rad_commands path both feed the same combined result, preserving the safe password handling for the default deploy. - Update the design note: rad_commands input, allowed-command set, combined rad-commands-result output, and an alternatives entry for combined-vs-per-command artifacts. Related: #12118 Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com>
…ands Align the Repo Radius workflow with the updated spec (PR #12078): adopt the two-action model naming and the renamed GitHub Actions variables. - Rename .github/extension/radius-deploy.yml -> radius-run-rad-commands.yml and set its name to "Radius - Run rad Commands" (this is the run-rad-commands engine). - Rename the cloud/cluster Actions variables to the spec contract: - AWS_IAM_ROLE_ARN -> AWS_ROLE_ARN - RADIUS_K8S_CLUSTER -> AZURE_AKS_CLUSTER_NAME (Azure) / AWS_EKS_CLUSTER_NAME (AWS) - RADIUS_K8S_NAMESPACE -> KUBERNETES_NAMESPACE - Update README.md, the radius-deploy skill, and the deploy-workflow design note to match the new file name, workflow name, and variables. No behavior change beyond the variable/name renames. Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com>
sk593
approved these changes
Jun 30, 2026
6 of 12 tasks
sk593
pushed a commit
that referenced
this pull request
Jul 8, 2026
…12264) Adds onto #12250 the two items the Repo Radius feature spec requires for Investment 3 that aren't in the deploy workflow yet: the **`radius_commands` dispatch contract** and a **technical design note**. Targets the `add-deploy-workflow` branch so it folds into #12250. The feature spec (Step 3, Investment 3) defines the workflow's dispatch contract as `environment` + `radius_commands`: a single `rad` command string, or a JSON array of command strings run in order (the `rad` prefix omitted), so a frontend can drive arbitrary `rad` commands — not only a single deploy. This adds `radius_commands` as an **optional** input alongside the existing `image`: - When `radius_commands` is set, the workflow runs each command in order, stops on the first failure, and uploads each command's output as the `radius-output` artifact for incremental frontend polling (spec Step 5). - When it's empty, the workflow runs its existing default `rad deploy` of `.radius/app.bicep` with the `image`/`password` parameters — **current behavior is unchanged**. This keeps the convenient single-deploy path while making the documented multi-command contract available to frontends (Copilot app, CLI, etc.). `eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md` — the design doc Nicole requires for this feature. It documents Investments 3 & 4: the dispatch contract, the `RADIUS_TARGET_KUBECONFIG` seam, the UCP-credential + projected-OIDC- token model (AWS IRSA / Azure WI), state persistence, and the recipe-pack / image-build flow as implemented in #12250. - Co-authored design note (sk593 + sylvainsf) reflecting the #12250 implementation, not the earlier prototype. - The `radius-output` artifact uses the same SHA-pinned `upload-artifact` already in the workflow. - This pull request adds or changes features of Radius and has an approved issue (issue link required). Related: #12118 Builds on: #12250 - An overview of proposed schema changes is included in a linked GitHub issue. - [ ] Yes - [x] Not applicable - A design document is added or updated under `eng/design-notes/` in this repository, if new APIs are being introduced. - [x] Yes - [ ] Not applicable - The design document has been reviewed and approved by Radius maintainers/approvers. - [ ] Yes - [x] Not applicable - A PR for [resource-types-contrib](https://github.com/radius-project/resource-types-contrib/) is created, if resource types or recipes are affected by the changes in this PR. - [ ] Yes - [x] Not applicable - A PR for [dashboard](https://github.com/radius-project/dashboard/) is created, if the Radius Dashboard is affected by the changes in this PR. - [ ] Yes - [x] Not applicable - A PR for the [documentation repository](https://github.com/radius-project/docs) is created, if the changes in this PR affect the documentation or any user facing updates are made. - [ ] Yes - [x] Not applicable --------- Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com>
sk593
pushed a commit
that referenced
this pull request
Jul 8, 2026
…12264) Adds onto #12250 the two items the Repo Radius feature spec requires for Investment 3 that aren't in the deploy workflow yet: the **`radius_commands` dispatch contract** and a **technical design note**. Targets the `add-deploy-workflow` branch so it folds into #12250. The feature spec (Step 3, Investment 3) defines the workflow's dispatch contract as `environment` + `radius_commands`: a single `rad` command string, or a JSON array of command strings run in order (the `rad` prefix omitted), so a frontend can drive arbitrary `rad` commands — not only a single deploy. This adds `radius_commands` as an **optional** input alongside the existing `image`: - When `radius_commands` is set, the workflow runs each command in order, stops on the first failure, and uploads each command's output as the `radius-output` artifact for incremental frontend polling (spec Step 5). - When it's empty, the workflow runs its existing default `rad deploy` of `.radius/app.bicep` with the `image`/`password` parameters — **current behavior is unchanged**. This keeps the convenient single-deploy path while making the documented multi-command contract available to frontends (Copilot app, CLI, etc.). `eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md` — the design doc Nicole requires for this feature. It documents Investments 3 & 4: the dispatch contract, the `RADIUS_TARGET_KUBECONFIG` seam, the UCP-credential + projected-OIDC- token model (AWS IRSA / Azure WI), state persistence, and the recipe-pack / image-build flow as implemented in #12250. - Co-authored design note (sk593 + sylvainsf) reflecting the #12250 implementation, not the earlier prototype. - The `radius-output` artifact uses the same SHA-pinned `upload-artifact` already in the workflow. - This pull request adds or changes features of Radius and has an approved issue (issue link required). Related: #12118 Builds on: #12250 - An overview of proposed schema changes is included in a linked GitHub issue. - [ ] Yes - [x] Not applicable - A design document is added or updated under `eng/design-notes/` in this repository, if new APIs are being introduced. - [x] Yes - [ ] Not applicable - The design document has been reviewed and approved by Radius maintainers/approvers. - [ ] Yes - [x] Not applicable - A PR for [resource-types-contrib](https://github.com/radius-project/resource-types-contrib/) is created, if resource types or recipes are affected by the changes in this PR. - [ ] Yes - [x] Not applicable - A PR for [dashboard](https://github.com/radius-project/dashboard/) is created, if the Radius Dashboard is affected by the changes in this PR. - [ ] Yes - [x] Not applicable - A PR for the [documentation repository](https://github.com/radius-project/docs) is created, if the changes in this PR affect the documentation or any user facing updates are made. - [ ] Yes - [x] Not applicable --------- Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com> Signed-off-by: sk593 <shruthikumar@microsoft.com>
pull Bot
pushed a commit
to TheTechOddBug/radius
that referenced
this pull request
Jul 9, 2026
… actions, docs) (radius-project#12348) ## Summary Adds the **repo-based Radius deploy workflow** — the GitHub Actions contract, provider-specific reusable workflows, shared composite actions, design note, and skill docs that let a repository deploy a Radius application to AKS/EKS from CI. This consolidates the work previously staged on `add-deploy-workflow` (PRs radius-project#12264, radius-project#12343, radius-project#12345) plus the latest doc sync into a single PR targeting `main`. ## What's included - **`.github/extension/`** — the workflow templates committed into user repos: - `run-rad-commands.yml` — unified dispatcher (routes to a provider via an `environment`-bound `detect` job). - `run-rad-commands-azure.yml` / `run-rad-commands-aws.yml` — provider-specific reusable (`workflow_call`) workflows. Azure downloads the `azure-avm` recipe pack from `resource-types-contrib`; AWS generates an inline `aws-terraform` pack. - `README.md` — the workflow contract (trigger/inputs, required `vars`, secrets, prerequisites). - **`.github/extension/actions/*`** — shared composite actions for the provider-agnostic phases: `setup-control-plane`, `restore-state`, `run-rad-commands`, `teardown`. - **`.github/skills/radius-deploy/SKILL.md`** — operator/agent skill describing the deploy flow and common failure modes. - **`eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md`** — the design note. - **noncloud functional test** updates (`statestore_lifecycle_test.go`, `functional-test-noncloud.yaml`, `build/test.mk`) covering state-store save/restore lifecycle. ## Key design points - **No resource-type registration at deploy time.** The `Radius.Compute/containerImages` type ships with the published `radius` Bicep extension, so the workflow no longer registers types or builds a local Bicep extension. - **App-directory deploy.** `radius-env.bicep` is written to and deployed from the app file's directory (e.g. `.radius/`) so `rad deploy` resolves the repo's own `bicepconfig.json` (which declares the `radius` extension). bicep resolves the config nearest the `.bicep` file. - **Ephemeral control plane.** Each run stands up a k3d Radius control plane on the runner, points it at the target AKS/EKS cluster, restores state from a `radius-state` git orphan branch, deploys, and tears down — persisting state again on the way out. ## Verification End-to-end Azure deploy verified working against a live AKS cluster with the AVM recipe pack. --------- Signed-off-by: sk593 <shruthikumar@microsoft.com> Signed-off-by: Shruthi Kumar <shruthikumar2401@gmail.com> Signed-off-by: Sylvain Niles <sylvainniles@microsoft.com> Co-authored-by: Sylvain Niles <sylvainniles@microsoft.com> Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds onto #12250 the two items the Repo Radius feature spec requires for
Investment 3 that aren't in the deploy workflow yet: the
radius_commandsdispatch contract and a technical design note. Targets the
add-deploy-workflowbranch so it folds into #12250.What this adds
radius_commandsdispatch input (additive —imageunchanged)The feature spec (Step 3, Investment 3) defines the workflow's dispatch contract as
environment+radius_commands: a singleradcommand string, or a JSON array ofcommand strings run in order (the
radprefix omitted), so a frontend can drivearbitrary
radcommands — not only a single deploy.This adds
radius_commandsas an optional input alongside the existingimage:radius_commandsis set, the workflow runs each command in order, stops onthe first failure, and uploads each command's output as the
radius-outputartifact for incremental frontend polling (spec Step 5).
rad deployof.radius/app.bicepwith theimage/passwordparameters — current behavior isunchanged.
This keeps the convenient single-deploy path while making the documented
multi-command contract available to frontends (Copilot app, CLI, etc.).
Technical design note
eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md— the designdoc Nicole requires for this feature. It documents Investments 3 & 4: the dispatch
contract, the
RADIUS_TARGET_KUBECONFIGseam, the UCP-credential + projected-OIDC-token model (AWS IRSA / Azure WI), state persistence, and the recipe-pack /
image-build flow as implemented in #12250.
Notes
not the earlier prototype.
radius-outputartifact uses the same SHA-pinnedupload-artifactalready inthe workflow.
Type of change
Related: #12118
Builds on: #12250
Contributor checklist
eng/design-notes/in this repository, if new APIs are being introduced.