Keep Repo Radius action workflows up to date (Repo Radius User Story 4.1) #106

Context

In the Repo Radius model, Repo Radius is delivered as two published GitHub Actions (radius-project/verify-cloud-auth and radius-project/run-rad-commands) that the frontend commits into the repository as thin workflows under .github/workflows, with each uses statement pinned to an exact commit SHA. The frontend and Repo Radius are independently versioned: updating the frontend does not change the pinned workflows, so they can drift apart.

The Radius Canvas extension must update the commit SHA on the Repo Radius actions in the workflows stored in the user's repository.

This issue tracks implementing that upgrade behavior in the Radius Canvas extension.

Source: Repo Radius feature specification, User Story 4.1 "Upgrade Repo Radius" (radius-project/radius#12078).

Scope

1. Pin on write. When creating an environment, write the Repo Radius workflows to .github/workflows with each uses statement pinned to an exact commit SHA so every run is reproducible.

2. Check at deploy time. Before dispatching a deployment, compare the action versions pinned in the repository's workflows against the versions the current frontend requires.

   • If they already match, proceed with the deployment; the developer sees nothing.
   • If a newer version is required, tell the developer the workflows must be updated and ask for confirmation before changing anything in the repository.

3. Update through a branch-protection-aware path. On confirmation, write the new SHAs into the workflows through whichever path the repository allows:

   • Attempt a direct commit to the default branch.
   • If the default branch is protected, offer to open a pull request with the updated workflows instead.
   • If the developer lacks permission to open that pull request, the workflows cannot be updated and the deployment does not proceed.

4. Deploy after update. Once the updated workflows are present, proceed with the up-to-date actions.

Acceptance criteria

• Workflows are written to .github/workflows with uses pinned to an exact commit SHA.
• At deploy time, the frontend detects when pinned actions are older than the versions it requires.
• When up to date, deployment proceeds with no prompt.
• When an update is needed, the developer is prompted and nothing changes without confirmation.
• Update applies via direct commit to the default branch, falling back to a pull request when the branch is protected.
• When the developer cannot open the required pull request, the deployment is blocked with a clear message.
• The upgrade is explicit and auditable (arrives via a direct commit or a reviewed pull request).