docs(design): sync default resource types without a fake Go module#12236
Open
DariuszPorowski wants to merge 5 commits into
Open
docs(design): sync default resource types without a fake Go module#12236DariuszPorowski wants to merge 5 commits into
DariuszPorowski wants to merge 5 commits into
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds a new design note describing how Radius should stop using a “fake” Go module dependency to pin and sync default resource-type manifests from radius-project/resource-types-contrib, replacing the transport with a direct, pinned fetch (Phase A) and outlining a longer-term release-asset / OCI-artifact model (Phase B).
Changes:
- Adds a detailed design proposal for ref-based syncing (Phase A) that removes the Go module + blank-import shim pattern.
- Specifies an end-state transport using GitHub Release assets (with optional OCI+cosign hardening) while keeping the existing copy/prune/drift-check skeleton.
- Documents intended updates to Make targets and the CI drift workflow at a design level.
Contributor docs impact (advisory):
- No updates required in
docs/contributing/ordocs/architecture/for this PR since it only adds a design note. - When this design is implemented,
docs/contributing/contributing-releases/README.mdwill likely need updates because it currently describes bumpinggo.modforresource-types-contrib(e.g., around the “Update default resource types” step).
nithyatsu
reviewed
Jun 25, 2026
|
|
||
| 1. **Remove the fake Go module.** Delete the `go.mod`/`doc.go` from `resource-types-contrib`, the `require` entry from Radius's `go.mod`/`go.sum`, and the blank-import shim `pkg/resourcetypescontrib/import.go`. Radius's Go dependency graph should contain only real Go dependencies. | ||
| 2. **Preserve the 2026-04 outcome.** Keep Radius-side ownership of the default set (`defaults.yaml`), full YAML-diff visibility in Radius PRs, version pinning with an audit trail, and CI drift detection. | ||
| 3. **Pin to an immutable, auditable revision** of upstream (commit SHA, tag, or OCI digest) with a readable record of what version is in use. |
Contributor
There was a problem hiding this comment.
pinning to an immutable version: this is needed for recipe-pack too. Would it be in scope we able able to specify a single pin (corresponding to a resource-type-contrib "release") and let both recipe-pack and type use it?
|
|
||
| #### Proposed Option | ||
|
|
||
| Adopt **Option 3 (pinned git-ref fetch) now** - it needs no upstream changes and removes the fake module immediately. Adopt **Option 4 (pinned GitHub Release asset) as the end state** - published by a minimal `resource-types-contrib` release workflow (not GoReleaser) and consumed on the radius side in line with the radius GoReleaser refactor - with **Option 5 (signed OCI artifact)** as an optional registry-and-signing upgrade. Phase B is sequenced with the radius core repo's GoReleaser work and the new contrib release workflow. Layer **Option 6 (sync bot)** on top once a transport is in place. This supersedes only the _transport_ of the [2026-04 design](2026-04-automated-default-resource-type-registration.md); its copy-based outcome (files committed in Radius, `defaults.yaml` in Radius, drift check) is preserved exactly. |
Contributor
There was a problem hiding this comment.
I think we should design for automated Dependabot-like sync from the start for releases and latest/main/edge
Member
Author
There was a problem hiding this comment.
Phase A + hybrid with sync (via PR)
Reshrahim
reviewed
Jun 25, 2026
|
|
||
| This is an internal contributor/release workflow. There is no change to the `rad` CLI, Bicep authoring, or any end-user surface. | ||
|
|
||
| **Sample Input - bump the pinned version and re-sync (Phase A):** |
Contributor
There was a problem hiding this comment.
Is tagging resource-types-contrib to a release is a pre-requisite to this step ?
brooke-hamilton
left a comment
brooke-hamilton
left a comment
Member
There was a problem hiding this comment.
I like this plan. I recommend approval.
| repo: github.com/radius-project/resource-types-contrib | ||
| # Phase A: a commit SHA (immutable) or branch/tag. | ||
| # Phase B: a release tag; a checksum/digest is recorded alongside for verification. | ||
| ref: 51ee446a8fc6c0c0a1b2c3d4e5f6071829304152 |
Member
There was a problem hiding this comment.
I like how this approach keeps the sha with the schema registration in the same file.
willtsai
reviewed
Jun 25, 2026
DariuszPorowski
force-pushed
the
dp/sudden-stoat-emerald
branch
from
598dcfa to
7ed8192
Compare
Signed-off-by: Dariusz Porowski <[email protected]>
Signed-off-by: Dariusz Porowski <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]> Signed-off-by: Dariusz Porowski <[email protected]>
…ization Signed-off-by: Dariusz Porowski <[email protected]>
…Dependabot-like PRs Signed-off-by: Dariusz Porowski <[email protected]>
DariuszPorowski
force-pushed
the
dp/sudden-stoat-emerald
branch
from
7ed8192 to
da12ae1
Compare
10 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Design: Sync default resource types without a fake Go module
Problem
Radius syncs its default resource-type manifests from
radius-project/resource-types-contrib— a repo that contains only YAML manifests and recipes, no Go code. To fetch a pinned snapshot, the current model turns that repo into a "fake Go module" (ago.modplus a placeholderdoc.go) purely so Go's module cache can act as a versioned file downloader. That phantom dependency:go.mod/go.sumand every supply-chain report (SBOM, license, vulnerability scanners, Dependabot) with a module that ships no code,v0.0.0-2026…-51ee446) instead of readable versions, andpkg/resourcetypescontrib/import.go) whose only job is to stopgo mod tidyfrom removing it.Value
This design replaces only the fetch transport and keeps everything good about the current model — Radius-side ownership of the default set, full YAML-diff visibility in PRs, version pinning, and CI drift detection.
Result: a clean Go dependency graph, human-readable versions, and accurate supply-chain reports — with no change to runtime registration (
RegisterDirectory) or the default set.Type of change
Contributor checklist
Please verify that the PR meets the following requirements, where applicable:
eng/design-notes/in this repository, if new APIs are being introduced.