Migrate Radius and AWS Bicep extensions from ACR to GHCR

[willdavsmith]

Engineering Improvement

Area for Improvement

Radius publishes and distributes the Radius and AWS Bicep extensions through Azure Container Registry (ACR):

• br:biceptypes.azurecr.io/radius:<tag>
• br:biceptypes.azurecr.io/aws:<tag>

Now that Azure/bicep#18956 added OCI registry support, migrate these public extension artifacts to GitHub Container Registry (GHCR). This should cover publishing, generated and checked-in bicepconfig.json files, CI, documentation, samples, and other consumers across the radius-project and azure-octo organizations.

Observed behavior

The current setup has several coupled dependencies on ACR:

• azure-octo/radius-publisher/.github/workflows/publish-bicep-types.yml and publish-bicep-types-aws.yml publish both extensions to biceptypes.azurecr.io using Azure OIDC and the BICEP_TYPES_AZURE_* secrets.
• radius-project/radius dispatches those private publisher workflows from its build/release automation.
• Radius currently ships and downloads Bicep CLI v0.42.1 from build/tools.yaml, build/tools.generated.mk, and pkg/cli/bicep/tools/download_tools.go. Generic OCI registry support requires Bicep v0.45.6 or newer.
• GHCR support is still gated by Bicep's experimentalFeaturesEnabled.ociEnabled setting. Existing Radius-generated and checked-in configurations enable extensibility but not ociEnabled.
• An audit found ACR extension references in Radius CLI scaffolding, generated configs, functional-test workflows, docs, samples, release scripts, agent assets, and satellite repositories. The actionable default-branch references span at least radius, bicep-types-aws, docs, samples, recipes, resource-types-contrib, ai-extensions, app-assembly-eval, github-extension, skills, lab, and azure-octo/radius-demo.
• Existing released Radius binaries and repository release branches embed the ACR references, so removing ACR artifacts immediately would break older releases.
• No public GHCR packages currently exist for the proposed Radius and AWS extension names.

Desired behavior

• Radius and AWS Bicep extensions are published as public GHCR OCI packages, for example:
  • br:ghcr.io/radius-project/bicep-types-radius:<tag>
  • br:ghcr.io/radius-project/bicep-types-aws:<tag>
• GHCR uses edge for development and latest for the newest approved stable release; ACR retains development latest for compatibility. Release-channel and release-version tags follow the Radius release policy.
• New Radius installs and generated bicepconfig.json files restore the extensions anonymously from GHCR without Azure credentials.
• The Radius-distributed Bicep CLI supports GHCR publishing and restore, and generated configurations enable ociEnabled while it remains required.
• Publishing uses GitHub package permissions and repository-scoped credentials rather than Azure registry credentials.
• Existing ACR artifacts remain readable for released Radius versions until their compatibility window ends.
• Tests prevent new production references to biceptypes.azurecr.io after cutover.

Proposed Fix

Use a phased, dual-publish migration rather than a flag-day cutover:

1. Define the artifact contract

   • Confirm GHCR package names and tag policy.
   • Inventory the ACR tags that must be mirrored.
   • Define how long ACR remains available for compatibility.

2. Upgrade and enable the Bicep toolchain

   • Upgrade Radius from Bicep v0.42.1 to a stable version containing the OCI support from OCI registry support for Bicep extension publishing Azure/bicep#18956.
   • Update the tool pin, checksums, rad bicep download, and related tests.
   • Add ociEnabled: true wherever Radius generates a GHCR-backed bicepconfig.json.
   • Configure BICEP_TRUSTED_REGISTRIES for local OCI registries used by CI so the Bicep upgrade does not regress non-cloud functional tests.
   • Ensure rad bicep publish-extension can publish to GHCR with Docker/GitHub credentials.

3. Establish GHCR publishing while retaining ACR publishing

   • Publish the Radius extension from radius-project/radius and the AWS extension from radius-project/bicep-types-aws, or update the delegated publisher with an equivalent least-privilege design.
   • Use packages: write, GITHUB_TOKEN, and Docker credentials expected by Bicep's OCI transport.
   • Associate each package with its source repository and make it public so consumers can restore anonymously.
   • Mirror currently supported tags to GHCR.
   • Dual-publish identical artifacts to ACR and GHCR for at least one stable Radius release.

4. Cut over Radius defaults

   • Update CLI scaffolding, build/scripts/generate-bicepconfig.sh, repository configs, Make examples, functional-test configs, workflow messages, tests, and agent assets.
   • Ship the hostname change and OCI-capable Bicep CLI in the same Radius release. Do not backport only the hostname to releases that ship Bicep v0.42.1.
   • Verify a clean rad bicep download and rad init can build and deploy templates using both Radius and AWS extensions from GHCR.

5. Migrate documentation, samples, and satellite consumers

   • Update radius-project/docs, samples, recipes, resource-types-contrib, ai-extensions, app-assembly-eval, github-extension, skills, and active lab or azure-octo consumers.
   • Update sample release automation so release branches retain the correct GHCR channel tag.
   • Consolidate obsolete per-namespace aliases such as radiusCompute, radiusData, and radiusSecurity onto the unified radius extension rather than creating extra GHCR packages.
   • Leave historical design notes, release notes, and blog posts unchanged or explicitly mark their ACR references as historical.

6. Retire ACR writes

   • After a stable dual-publish observation period, disable ACR publishing and remove publisher-only Azure credentials.
   • Keep existing ACR artifacts readable for older released clients.
   • Add a CI check that rejects new actionable references to biceptypes.azurecr.io.

7. Remove the experimental flag when Bicep graduates OCI support

   • Track upstream Bicep stabilization and remove generated ociEnabled settings only after the minimum shipped Bicep version no longer requires them.

Acceptance criteria:

• Public Radius and AWS extension packages exist in GHCR and can be restored anonymously with the Radius-shipped Bicep CLI.
• During dual publishing, each extension's ACR latest and GHCR edge resolve to the same manifest digest; same-name release-channel and RC tags also match. Consumer cutover requires remapping development references from ACR latest to GHCR edge; GHCR latest identifies the newest approved stable release.
• New Radius-generated configs use GHCR and include every required Bicep feature setting.
• Radius build, non-cloud functional tests, cloud functional tests, and long-running release tests pass with the upgraded Bicep CLI.
• Documentation and active samples reference GHCR.
• No actionable default-branch production references to biceptypes.azurecr.io remain outside explicit compatibility or historical content.
• ACR publishing is retired only after the agreed compatibility and observation period.

System information

rad Version

N/A — this is a cross-repository publishing and distribution migration. The current Radius source pins Bicep CLI v0.42.1.

Operating system

N/A — the change affects GitHub Actions publishers and all platforms supported by the Radius-distributed Bicep CLI.

Additional context

• Upstream OCI support: OCI registry support for Bicep extension publishing Azure/bicep#18956
• Bicep OCI documentation: https://github.com/Azure/bicep/blob/main/docs/experimental/oci-registries.md
• GitHub Container Registry documentation: https://docs.github.com/packages/working-with-a-github-packages-registry/working-with-the-container-registry
• Related historical issues Switch ACR/Blob storage references to GHCR and Release respectively #6291, Store edge version rad cli and bicep binary in GHCR #6295, and Cleanup bicep GHCR upload workflow  #6898 concern Radius/Bicep binary storage rather than migration of the Radius and AWS Bicep extension packages.

[radius-triage]

👋 @willdavsmith Thanks for filing this issue.

A project maintainer will review this issue and get back to you soon.

We also welcome community contributions! If you would like to pick this item up sooner and submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.

For more information on our triage process please visit our triage overview

[kachawla]

Cross-linking some newly filed work that intersects this migration.

Today the Radius and AWS Bicep extensions are published under a mutable <major>.<minor> channel tag that each patch release overwrites, so there is no immutable per-version artifact. Since patch releases are permitted to change resource types, that has a few live consequences (stale caches, no reproducibility, no rollback path).

• Decide the Bicep extension tagging policy: stop overwriting release channel tags #12959 decides the tagging policy — whether to stop overwriting channel tags, and what bicepconfig.json should pin.
• Enforce tag immutability and provenance for published Bicep extension artifacts #12964 covers registry-side enforcement of tag immutability.

#12964 is the piece most relevant here: the immutability settings have to be configured on the destination repositories as part of this migration anyway, so it is likely cheaper to land together with the move than to retrofit afterwards. Flagging it now so the requirement is not lost when this issue closes.

[radius-triage]

👍 We've reviewed this issue and have agreed to add it to our backlog. Please subscribe to this issue for notifications, we'll provide updates when we pick it up.

We also welcome community contributions! If you would like to submit a pull request, please visit our contribution guidelines and assign this to yourself by commenting "/assign" on this issue.

For more information on our triage process please visit our triage overview

[nicolejms]

Current implementation and remaining work

Implemented: #12951 and #12980 established the GHCR migration design, and #13075 upgraded the Bicep publishing path with OCI-capable tooling.

Remaining: Radius and AWS Bicep extension publication has not fully cut over from ACR to GHCR, and consumer/scaffolding references are not yet migrated end to end. The follow-up publishing work, including #13119, remains open.