Design: Unified Bicep extension publishing for default resource types by kachawla · Pull Request #11892 · radius-project/radius

kachawla · 2026-05-14T10:31:08Z

Description

This design proposes consolidating the per-namespace Bicep extensions for default resource types (radiusCompute, radiusData, radiusSecurity) into a single published extension, and automating the publishing process to stay in sync with the default resource type registration list (defaults.yaml).

Options

Option 1 (proposed): Separate radiusResources extension - Merges contrib namespaces into one extension at br:biceptypes.azurecr.io/radiusresources. Go-only changes, independent pipeline, straightforward automation for both versioned and latest publishing.

Option 2: Merge into existing radius extension - Single extension for everything. Best UX but couples two generation pipelines (TypeScript + Go) and complicates latest publishing from contrib CI.

Key decisions to review

Option 1 vs Option 2 for extension consolidation
Automation approach for versioned (release pipeline) and latest (contrib CI) publishing

Type of change

Fixes: #issue_number

Contributor checklist

Please verify that the PR meets the following requirements, where applicable:

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

Copilot

Pull request overview

This PR adds a design note proposing how Radius should consolidate and automate publishing of Bicep extensions for default resource types from resource-types-contrib.

Changes:

Documents the current per-namespace Bicep extension publishing model.
Compares separate radiusResources publishing versus merging into the existing radius extension.
Proposes Option 1 and outlines publishing automation for versioned and latest artifacts.

kachawla · 2026-05-14T17:41:45Z

+
+Today, Bicep extensions for resource types from `resource-types-contrib` are published as separate per-namespace extensions (`radiusCompute`, `radiusData`, `radiusSecurity`), each at its own OCI registry path. This requires users to configure multiple extension entries in `bicepconfig.json` and authors to use different `extension` directives depending on the namespace. Meanwhile, the core Radius extension (`radius`) already bundles multiple namespaces (`Applications.Core`, `Applications.Dapr`, `Applications.Datastores`, `Applications.Messaging`, `Radius.Core`) in a single published artifact.
+
+This design proposes consolidating the contrib-sourced Bicep extensions into fewer (ideally one) published artifacts, and automating the publishing process so it stays in sync with the default resource type registration introduced in the [default registration design](2026-04-automated-default-resource-type-registration.md).


default registration design

this link doesn't work right now since the PR is pending merge. You can use https://github.com/kachawla/radius/blob/63e928eaf9e326ab1048a0d5650b8efdb93c747a/eng/design-notes/extensibility/2026-04-automated-default-resource-type-registration.md in the meantime.

Reshrahim · 2026-05-14T18:10:14Z

+
+### Proposed option
+
+**Option 1: Separate `radiusResources` extension.** This is simpler to implement, keeps the build pipelines independent, and makes automation for both versioned and latest publishing straightforward. The extra `extension radiusResources` directive is a minor user-facing cost compared to the build and operational complexity of merging two generation pipelines. Option 2 (merging into `radius`) can be a future enhancement if the user experience benefit justifies aligning the pipelines.


What is the cost of renaming radiusResources to radius after we have deprecated the Application.* types?

Deprecation of Application.* won't impact this because radius also includes new Radius.core namespace

I meant after removing Application.containers and Aaplications.Data/* we move back to extension radius

sorry I still don't follow how removal of those resource types will help.. could you share more?

DariuszPorowski · 2026-05-14T18:11:07Z

+}
+```
+
+The `radius` extension is generated by a **TypeScript autorest pipeline** from Swagger/OpenAPI specs and bundles 5 namespaces. The contrib extensions (`radiusCompute`, `radiusData`, `radiusSecurity`) are each published separately using `rad bicep publish-extension` from individual YAML manifests via the **Go-based `bicep-tools` converter**.


note: autorest is deprecated, we should plan migration to typespec soon

willtsai · 2026-05-14T18:14:16Z

+- If the contrib types have issues, it could block the core `radius` extension from being published
+- More complex build pipeline with two generation steps feeding into one output
+
+### Proposed option


I would rather have Option 2 as I think the simplified user experience outweighs the cons of the build pipeline.

we have them as one extension or have them split out like it is today and users can select what extensions/they want to include. having two extensions is not entirely intuitive but that's just one input

Discussed and decided to go ahead with option 2. Updated the doc https://github.com/kachawla/radius/blob/bed122aa133d914f8f7c3055ab561eb9c0e16d60/eng/design-notes/extensibility/2026-05-unified-bicep-extension-publishing.md#decision

willdavsmith · 2026-05-14T18:15:31Z

+{
+  "extensions": {
+    "radius": "br:biceptypes.azurecr.io/radius:latest",
+    "radiusResources": "br:biceptypes.azurecr.io/radiusresources:latest",


would it be possible to contribute upstream to Bicep CLI and ask if we can special-case the "resource not found" error for radius resources? I imagine this will be a common failure case

could you remind me what error does it return today?

brooke-hamilton

How is the consolidated extension versioned when one of the types has a version update?

nithyatsu · 2026-05-14T18:16:06Z

+
+**Disadvantages:**
+- Users need two Radius-related extensions (`radius` and `radiusResources`). Not that bad as we can automatically generate the `radiusResources` entry in `bicepconfig.json` and document it as the extension for all non-core resource types.
+


keeping rrts seperate from core radius schema feels like a better choice to me.

lakshmimsft · 2026-05-14T21:08:22Z

+- **Breaking change for existing users:** Users currently using `extension radiusCompute` / `extension radiusData` / `extension radiusSecurity` in their Bicep files will need to update to `extension radiusResources` for Option 1. This should be communicated in release notes. However, since these types were recently made available as defaults, the user base is likely small.
+- **bicepconfig.json update:** Users will need to update `bicepconfig.json` to remove the old entries. A migration guide or `rad init` update should handle this.
+
+## Development plan


Note: Assess if publishing types for cloud/non-cloud/lrt functional tests is affected/needs to be updated.

@lakshmimsft could you say more on this? Do we publish a separate extension for core types instead of using radius extension for tests currently?

eg. in non-cloud functional tests, we publish extensions for radius types and test types to a local registry link and generate a temp bicepconfig file while in cloud/lrt tests we publish to the test acr for bicep types link

ah I see, good point. It looks like it will need to be updated but not immediately because we don't use any of the default Radius types in our functional tests yet. I'll see if it is possible to include it in the implementation, else we'll have to track it as a follow up when we are adding tests.

Investigated this and here's the impact:

The both the functional test workflows call make generate-bicep-types, which now includes the contrib types. Two things needed:

yq install -- the contrib types requires yq to parse defaults.yaml. Added an explicit install step to both workflows in #11915, same pattern as verify-resource-types.yaml

No functional test changes are needed once we start using contrib types in the tests since bicepconfig already covers radius extension.

kachawla · 2026-05-15T00:16:28Z

How is the consolidated extension versioned when one of the types has a version update?

This is the tradeoff of bundling multiple types in one extension :/, we don't have versions tied to one type. Bumping any single type would result into publishing latest tag of the whole extension (in case of radiusResource extension, will have to see how realistic it is to publish combined latest for single radius extension), or we bump the extension version whenever next Radius release happens.

Signed-off-by: Karishma Chawla <kachawla@microsoft.com>

radius-functional-tests · 2026-05-15T06:39:04Z

Radius functional test overview

🔍 Go to test action run

Click here to see the test run details

Name	Value
Repository	kachawla/radius
Commit ref	`c56a079`
Unique ID	funcb7aa93448e
Image tag	pr-funcb7aa93448e

gotestsum 1.13.0
KinD: v0.29.0
Dapr: 1.14.4
Azure KeyVault CSI driver: 1.4.2
Azure Workload identity webhook: 1.3.0
Bicep recipe location ghcr.io/radius-project/dev/test/testrecipes/test-bicep-recipes/<name>:pr-funcb7aa93448e
Terraform recipe location http://tf-module-server.radius-test-tf-module-server.svc.cluster.local/<name>.zip (in cluster)
applications-rp test image location: ghcr.io/radius-project/dev/applications-rp:pr-funcb7aa93448e
dynamic-rp test image location: ghcr.io/radius-project/dev/dynamic-rp:pr-funcb7aa93448e
controller test image location: ghcr.io/radius-project/dev/controller:pr-funcb7aa93448e
ucp test image location: ghcr.io/radius-project/dev/ucpd:pr-funcb7aa93448e
deployment-engine test image location: ghcr.io/radius-project/deployment-engine:latest

Test Status

⌛ Building Radius and pushing container images for functional tests...
✅ Container images build succeeded
⌛ Publishing Bicep Recipes for functional tests...
✅ Recipe publishing succeeded
⌛ Starting corerp-cloud functional tests...
⌛ Starting ucp-cloud functional tests...
✅ ucp-cloud functional tests succeeded
✅ corerp-cloud functional tests succeeded

…11914) ## Overview Update the existing `generate` subcommand of `manifest-to-bicep` to accept multiple manifest files. When given multiple YAML manifests with the same namespace, their `Types` maps are merged into a single output (`types.json`, `index.json`, `index.md`). This supports per-type manifest files (e.g. `containers.yaml`, `routes.yaml`) as introduced by the [automated resource type registration design](#11911), where each file defines a single resource type within a namespace. Backward compatible: single-file usage works exactly as before. ## Changes - `bicep-tools/cmd/manifest-to-bicep/main.go`: Updated `generate` to accept `<manifest1> [manifest2...] <output>` (last arg is always output dir). Added `mergeManifestFiles()` that validates same namespace and rejects duplicate types. - `bicep-tools/cmd/manifest-to-bicep/main_test.go`: Added tests for single-file, multi-file merge, namespace mismatch, nonexistent file, empty manifest list, and duplicate type detection. - `bicep-tools/cmd/manifest-to-bicep/testdata/`: Added test manifest files for `Radius.Compute` (containers, routes) and `Radius.Security` (secrets). ## Usage Single file (backward compatible): ```bash go run ./bicep-tools/cmd/manifest-to-bicep generate containers.yaml /tmp/out ``` Multiple files (merge into one output): ```bash go run ./bicep-tools/cmd/manifest-to-bicep generate containers.yaml routes.yaml persistentVolumes.yaml /tmp/out ``` ## Test plan - `go test ./bicep-tools/cmd/manifest-to-bicep/` - 6 tests covering single-file generation, multi-file merge, namespace mismatch rejection, nonexistent file handling, empty input, and duplicate type detection. ## Part of Unified Bicep extension publishing (PR 1/4). See [design doc](#11892). ## Dependencies - [Automated default resource type registration](#11911) (provides `defaults.yaml` and per-type manifest files that this command consumes) --------- Signed-off-by: Karishma Chawla <kachawla@microsoft.com>

Copilot AI review requested due to automatic review settings May 14, 2026 10:31

kachawla requested review from a team as code owners May 14, 2026 10:31

Copilot started reviewing on behalf of kachawla May 14, 2026 10:31 View session

Copilot AI reviewed May 14, 2026

View reviewed changes

kachawla added the pr:standard label May 14, 2026

This was referenced May 14, 2026

Investigate Merging Extensions for All Resource Types into One #11831

Open

[Design] Automate publishing extensions #11487

Open

kachawla force-pushed the publish-extensions branch from 716e105 to da5ffd7 Compare May 14, 2026 10:46

kachawla commented May 14, 2026

View reviewed changes

kachawla force-pushed the publish-extensions branch from da5ffd7 to 8731505 Compare May 14, 2026 18:04

Reshrahim reviewed May 14, 2026

View reviewed changes

DariuszPorowski reviewed May 14, 2026

View reviewed changes

willtsai reviewed May 14, 2026

View reviewed changes

willdavsmith reviewed May 14, 2026

View reviewed changes

brooke-hamilton reviewed May 14, 2026

View reviewed changes

nithyatsu reviewed May 14, 2026

View reviewed changes

lakshmimsft reviewed May 14, 2026

View reviewed changes

Design: Unified Bicep extension publishing for default resource types

bed122a

Signed-off-by: Karishma Chawla <kachawla@microsoft.com>

kachawla force-pushed the publish-extensions branch from 8731505 to bed122a Compare May 15, 2026 00:52

kachawla requested review from Reshrahim, lakshmimsft, nithyatsu and willtsai May 15, 2026 04:24

Updates to reflect updates in automatic resource types sync design

c56a079

Signed-off-by: Karishma Chawla <kachawla@microsoft.com>

This was referenced May 15, 2026

feat: add multi-file merge support to generate command kachawla/radius#36

Closed

Add multi-file merge support to manifest-to-bicep generate command #11914

Merged

Integrate contrib types into unified Bicep extension #11915

Open

This was referenced May 15, 2026

Add workflow to notify Radius repo on contrib updates radius-project/resource-types-contrib#160

Open

Add workflow to sync contrib resource types and publish Bicep extensions #11916

Open

Merge branch 'main' into publish-extensions

4e26330


		Today, Bicep extensions for resource types from `resource-types-contrib` are published as separate per-namespace extensions (`radiusCompute`, `radiusData`, `radiusSecurity`), each at its own OCI registry path. This requires users to configure multiple extension entries in `bicepconfig.json` and authors to use different `extension` directives depending on the namespace. Meanwhile, the core Radius extension (`radius`) already bundles multiple namespaces (`Applications.Core`, `Applications.Dapr`, `Applications.Datastores`, `Applications.Messaging`, `Radius.Core`) in a single published artifact.

		This design proposes consolidating the contrib-sourced Bicep extensions into fewer (ideally one) published artifacts, and automating the publishing process so it stays in sync with the default resource type registration introduced in the [default registration design](2026-04-automated-default-resource-type-registration.md).


		### Proposed option

		Option 1: Separate `radiusResources` extension. This is simpler to implement, keeps the build pipelines independent, and makes automation for both versioned and latest publishing straightforward. The extra `extension radiusResources` directive is a minor user-facing cost compared to the build and operational complexity of merging two generation pipelines. Option 2 (merging into `radius`) can be a future enhancement if the user experience benefit justifies aligning the pipelines.


		Disadvantages:
		- Users need two Radius-related extensions (`radius` and `radiusResources`). Not that bad as we can automatically generate the `radiusResources` entry in `bicepconfig.json` and document it as the extension for all non-core resource types.

Conversation

kachawla commented May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Options

Key decisions to review

Type of change

Contributor checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lakshmimsft May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

brooke-hamilton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lakshmimsft May 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kachawla commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

radius-functional-tests Bot commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Radius functional test overview

Test Status

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

kachawla commented May 14, 2026 •

edited

Loading

lakshmimsft May 14, 2026 •

edited

Loading

lakshmimsft May 14, 2026 •

edited

Loading

kachawla commented May 15, 2026 •

edited

Loading

radius-functional-tests Bot commented May 15, 2026 •

edited

Loading