[willtsai]

Summary

Add a user-experience-focused Repo Radius specification covering temporary Radius execution in existing GitHub Actions and Azure DevOps pipelines, persistent Radius configuration and deployment state, external AKS/EKS/ACA/ECS workload targets, and jobs connected to an existing centralized Radius control plane.

The specification covers saved environment and recipe configuration, running existing Radius commands, clear status reporting, and explicitly requested application deletion. Separate scenarios describe command outcomes and diagnostics (Scenario 6) and running existing Radius deletion commands (Scenario 7). Automatic rollback, retry, and repair are out of scope; the pipeline or operator decides the next action. Release management and promotion remain in the team's existing pipelines. Implementation details are excluded, and first-release platform coverage remains an open question. The author is Will Tsai (@willtsai). The document lives under eng/design-notes/environments/ alongside the related deployment designs.

Reason for change

Related proposal: #12078.

This is an independently based, user-experience-focused alternative to #12078, not an implementation and not a stacked PR. The new branch starts directly from main at 6a0e8300b428e770b6eabbd046a495eb88ebb282 and contains only this specification. It separates where Radius runs from where applications run and describes how teams use Radius from existing CI/CD pipelines. This PR does not fix, close, retarget, or modify #12078 or its branch.

How to test

From the repository root, use Node.js 24 and npm. The commands below do not change dependency manifests or lockfiles:

npm exec --yes --package=markdown-table-formatter@1.7.0 -- markdown-table-formatter eng/design-notes/environments/2026-06-repo-radius.md --check
npm exec --yes --package=markdownlint-cli2@0.23.3 -- markdownlint-cli2 eng/design-notes/environments/2026-06-repo-radius.md --config .github/linters/.markdownlint-cli2.yaml
git diff --check origin/main...HEAD

Expect both Markdown checks and the whitespace check to exit successfully, with no lint violations. Review the rendered document to confirm the author is Will Tsai, the relative link to the external Kubernetes proposal resolves, and all seven scenarios describe user requirements rather than claims of current support. Scenario 5 should depend explicitly on the configuration preserved by Scenario 2. Scenario 6 should distinguish success, failure, cancellation, and unknown outcomes without promising automatic recovery. Scenario 7 should reuse existing Radius deletion behavior and distinguish application deletion from control-plane cleanup. Release coverage remains an open question; release management, promotion, and automatic rollback, retry, or repair are non-goals.

Validation performed with Node.js 24.20.0:

• npm exec --yes --package=markdown-table-formatter@1.7.0 -- markdown-table-formatter eng/design-notes/environments/2026-06-repo-radius.md --check — passed.
• npm exec --yes --package=markdownlint-cli2@0.23.3 -- markdownlint-cli2 eng/design-notes/environments/2026-06-repo-radius.md --config .github/linters/.markdownlint-cli2.yaml — passed, zero issues.
• git diff --check and git diff --cached --check — passed before committing.
• test -f eng/design-notes/environments/2026-05-external-kubernetes.md — passed during the earlier relocation; the link target is unchanged.

Tooling limitations encountered during initial validation: pnpm rejected the existing package-manager lockfile metadata, and npm returned ETARGET for the repository-pinned markdownlint-cli2@0.24.0. The lint result above uses the previously working 0.23.3 fallback, not the pinned 0.24.0; no dependency or lockfile changes were made.

Runtime tests, including make test, were not run: this PR contains documentation only and no executable changes.

File change summary

File	Summary of change
eng/design-notes/environments/2026-06-repo-radius.md	Add the Repo Radius user-experience specification authored by Will Tsai, covering temporary and centralized CI/CD execution, persistent configuration and deployment state, independent workload targets, approved environments and recipes, status reporting, explicit application deletion using existing Radius commands, and open release-coverage questions.

[github-actions]

Dependency Review

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

Scanned Files

None

[Copilot]

🟢 Approval recommended

The documentation-only specification is internally consistent, distinguishes intended capabilities from current support, and has no identified blocking issues.

No open issues 🎉

What changed in this PR

Adds a user-experience specification for using Radius in existing CI/CD pipelines, independently of where application workloads run. This is an alternative to proposal #12078, not an implementation.

Changes:

• Defines temporary and centralized control-plane execution in GitHub Actions and Azure DevOps.
• Describes persistent state, approved environments and recipes, application lifecycle operations, and recovery.
• Identifies intended workload targets while leaving first-release platform coverage open.

File	Description
eng/​design-notes/​github/​2026-06-repo-radius.md	Adds seven user scenarios, dependencies, risks, and open questions for Repo Radius.

_{Review effort: Balanced}