Skip to content

Add radius_commands dispatch contract + deploy-workflow design note - #12264

Merged
sylvainsf merged 5 commits into
add-deploy-workflowfrom
radius-commands-and-design-note
Jun 30, 2026
Merged

sylvainsf merged 5 commits into
add-deploy-workflowfrom
radius-commands-and-design-note

Conversation

@sylvainsf

Copy link
Copy Markdown
Contributor

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_commands
dispatch contract
and a technical design note. Targets the
add-deploy-workflow branch so it folds into #12250.

What this adds

radius_commands dispatch input (additive — image unchanged)

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

Technical design note

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.

Notes

  • Co-authored design note (sk593 + sylvainsf) reflecting the Add deploy workflow #12250 implementation,
    not the earlier prototype.
  • The radius-output artifact uses the same SHA-pinned upload-artifact already in
    the workflow.

Type of change

  • This pull request adds or changes features of Radius and has an approved issue (issue link required).

Related: #12118
Builds on: #12250

Contributor checklist

  • 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

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>
@github-actions

Copy link
Copy Markdown

Dependency Review

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

Scanned Files

None

@sylvainsf sylvainsf added the pr:standard Ongoing maintenance, minor improvements, documentation updates, and routine development work label Jun 26, 2026
@sylvainsf
sylvainsf marked this pull request as ready for review June 26, 2026 01:58
@sylvainsf
sylvainsf requested review from a team as code owners June 26, 2026 01:58
@sylvainsf sylvainsf mentioned this pull request Jun 26, 2026
6 of 12 tasks
@brooke-hamilton
brooke-hamilton requested a review from Copilot June 26, 2026 13:53

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_commands workflow_dispatch input to run either a single rad command string or a JSON array of commands, capturing output for artifact upload.
  • Capture command output into /tmp/radius-output and upload it as a radius-output artifact (plus update default deploy logging to tee into the same output directory).
  • Add eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md describing 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.

Comment thread .github/extension/radius-run-rad-commands.yml
Comment thread eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md Outdated
Comment thread eng/design-notes/environments/2026-06-repo-radius-deploy-workflow.md Outdated
Comment thread .github/extension/radius-deploy.yml Outdated
Comment thread .github/extension/radius-run-rad-commands.yml
- 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>
@sylvainsf
sylvainsf merged commit cd8fec5 into add-deploy-workflow Jun 30, 2026
5 checks passed
@sylvainsf
sylvainsf deleted the radius-commands-and-design-note branch June 30, 2026 21:21
@sylvainsf sylvainsf mentioned this pull request 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr:standard Ongoing maintenance, minor improvements, documentation updates, and routine development work

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants