[kachawla]

Description

Certain resource types defined in the resource-types-contrib repo are expected to be registered with Radius by default for every installation. The way we enable it today is by manually copying over the manifests into Radius repo and maintaining duplicate files. This design automates propagating the changes to the Radius repo.

Type of change

Fixes: #11108

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 PR is created in the design-notes 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 the samples repository is created, if existing samples are 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
• A PR for the recipes repository is created, if existing recipes are affected by the changes in this PR.
  • Yes
  • Not applicable

[Copilot]

Pull request overview

Adds a design note proposing automated default registration of Radius resource types by embedding selected manifests from resource-types-contrib into the Radius binary and registering them during UCP initialization.

Changes:

• Introduces a design for using resource-types-contrib as a Go module dependency and embedding default manifests via go:embed.
• Proposes a centralized defaults.yaml + go generate workflow to control which manifests ship as defaults.
• Describes initializer/runtime behavior, error handling, and a test/CI validation plan for generated embed lists.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.38%. Comparing base (9b812b3) to head (4177f2d).

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #11610   +/-   ##
=======================================
  Coverage   51.38%   51.38%           
=======================================
  Files         699      699           
  Lines       44114    44114           
=======================================
  Hits        22666    22666           
  Misses      19279    19279           
  Partials     2169     2169           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[brooke-hamilton]

🚀 I really like how this proposal sets up resource-types-contrib as a clear dependency of Radius via a Golang module dependecy.

[kachawla]

After speaking with @ryanwaite, we have decided to go with the alternative approach 1 from the design. defaults.yaml will be in the Radius repo instead of the proposed approach of keeping defaults.yaml in resource-types-contrib.

What this means:

• defaults.yaml will live in the radius repo under manifest
• A Makefile target reads defaults.yaml, downloads the pinned version of resource-types-contrib from the Go module cache, and copies the listed files into built-in-providers
• The copied YAML files are committed to the radius repo after PR review and registered at startup by the existing RegisterDirectory function
• resource-types-contrib remains a plain Go module with manifest YAML files

Why we chose Alternative approach 1 over the proposed approach:

• Radius maintainers have direct control over which resource types ship as defaults
• Full content visibility in Radius PRs (the actual YAML files are in the diff, not hidden behind a go.mod version bump)

Tradeoffs we're accepting:

• Adding a new default requires changes in both repos
• Risk of drift if the copy script is not re-run after dependency updates (mitigated by CI validation)

[kachawla]

PRs implementing the revised design -
radius-project/resource-types-contrib#158
#11911
#11912
radius-project/resource-types-contrib#161