Conversation
…m terms Signed-off-by: Dariusz Porowski <3431813+DariuszPorowski@users.noreply.github.com>
❌ Spellcheck FailedThere are spelling errors in your PR. Visit the workflow output to see what words are failing. Adding new wordsYou can add new custom words to .github/config/en-custom.txt. |
|
|
||
| Radius currently uses a custom release system spread across Make includes, shell steps, Python version parsing, multiple GitHub workflows, and a long manual process documented for release engineers. The result is a release lifecycle that is expensive to maintain, difficult to reason about, and slower to evolve than the product it serves. | ||
|
|
||
| This design proposes moving the Radius build and release lifecycle to GoReleaser as the single source of truth for Go binary compilation, archive creation, checksum generation, multi-architecture container image publication, GitHub Release creation, and changelog generation. The release flow becomes tag-driven: push a `v*` tag, let GoReleaser build and publish the release, and then run lightweight post-release coordination for sibling repositories and non-Go artifacts. |
|
|
||
| This design proposes moving the Radius build and release lifecycle to GoReleaser as the single source of truth for Go binary compilation, archive creation, checksum generation, multi-architecture container image publication, GitHub Release creation, and changelog generation. The release flow becomes tag-driven: push a `v*` tag, let GoReleaser build and publish the release, and then run lightweight post-release coordination for sibling repositories and non-Go artifacts. | ||
|
|
||
| This approach simplifies procedures, reduces maintenance cost, removes custom workflow complexity, and aligns Radius with a widely recognized release tool in the Go ecosystem and across CNCF-adjacent projects. It also creates a cleaner path for standardized supply-chain capabilities such as code signing, SBOM generation, provenance attestations, changelog automation, and more predictable version handling. |
There was a problem hiding this comment.
Our supply chain security requirements are only going to increase - the cleaner path is a more secure path in this context.
| * **GoReleaser**: A release automation tool for Go projects that can build binaries, package archives, publish container images, create GitHub Releases, and generate changelogs from git metadata. | ||
| * **Release lifecycle**: The end-to-end process for producing and publishing Radius binaries, container images, GitHub Releases, release notes, and downstream coordination. | ||
| * **Release channel**: The major and minor stream for a Radius release, such as `0.56`, used to group compatible artifacts and release branches. | ||
| * **Snapshot build**: A non-final build used for pull requests and branch validation, typically without publishing an official GitHub Release. |
There was a problem hiding this comment.
Would this also be pushed to Docker hub? (or wherever our image store is)
|
|
||
| * Make GoReleaser the single source of truth for Radius releaseable Go artifacts. | ||
| * Replace the current hand-rolled Makefile, shell, and Python release logic with declarative release configuration where practical. | ||
| * Reduce the current workflow complexity, including the existing multi-step manual release procedure and the duplication between local build logic and CI/CD workflows. |
There was a problem hiding this comment.
Would this also simplify CI workflows/validation?
There was a problem hiding this comment.
Certainly. I anticipate that approximately 80% of the existing workflows code will be eliminated.
|
|
||
| ### Non goals | ||
|
|
||
| * Rewriting every existing release-adjacent workflow in the first iteration. The scope is the core Radius build and release path. |
| * Rewriting every existing release-adjacent workflow in the first iteration. The scope is the core Radius build and release path. | ||
| * Moving all non-Go assets into GoReleaser immediately. The Helm chart, Bicep image, deployment-engine publication, and sibling repository dispatch remain separate where they are operationally distinct. | ||
| * Changing public Radius APIs or the end-user install experience as part of this design. | ||
| * Solving every supply-chain requirement in the first migration. This design enables later adoption of code signing, SBOMs, and attestations, but it does not require all of them on day one. |
| ##### Advantages of Option 3 | ||
|
|
||
| * Produces the biggest simplification in procedures and maintenance. | ||
| * Moves the common release concerns into a single declarative tool that many Go projects already understand. |
There was a problem hiding this comment.
This will be useful for new contributors (both internal and external).
|
|
||
| The authoritative release trigger becomes a pushed `v*` tag. The workflow computes release metadata such as `REL_CHANNEL` and `CHART_VERSION`, then invokes GoReleaser in release mode. | ||
|
|
||
| This replaces the current model where `versions.yaml` changes indirectly drive release automation. `versions.yaml` remains as documentation and release metadata for humans, but it is no longer the trigger for creating artifacts. |
There was a problem hiding this comment.
Is there a way this could be automatically updated by GoReleaser? (just to keep versions.yaml in sync with releases, not to drive releases)
There was a problem hiding this comment.
UPDATE - saw that you address this further down in the doc.
|
|
||
| The same GoReleaser configuration is used in snapshot mode for pull requests and branch pushes. Snapshot mode validates the release configuration, builds the same artifacts, and can optionally publish or save artifacts needed by functional tests without creating an official GitHub Release. | ||
|
|
||
| This is a substantial maintainability improvement because it makes the release behavior testable earlier and more often. |
There was a problem hiding this comment.
Agreed - this would be very useful for testing!
|
|
||
| GoReleaser generates a changelog from git history and can group entries into sections such as features, fixes, and breaking changes. Radius should standardize on conventional-commit style prefixes to improve changelog quality. | ||
|
|
||
| The recommended enforcement path is: |
There was a problem hiding this comment.
Is there a way to automate this enforcement?
There was a problem hiding this comment.
@nellshamrell it its! For PoC it has been implemented here: https://github.com/radius-project/wellknown/blob/main/.github/workflows/pr-title.yml
|
|
||
| #### Lightweight post-release coordination | ||
|
|
||
| Some actions should remain outside GoReleaser because they are not native release outputs of the main Go module. These include: |
There was a problem hiding this comment.
These are things will eventually want to automate as well, but they are definitely not necessary for a first iteration (and should not block adopting this first iteration).
| * Provenance and attestation publication. | ||
| * Richer OCI labels and metadata. | ||
|
|
||
| This design does not require all of these on day one, but it intentionally creates a release structure where adding them is incremental rather than architectural. |
There was a problem hiding this comment.
This is a good point - these things WILL be required in the nearish future and having an architecture which makes it straightforward to add them will be very helpful.
| * Non-root user behavior. | ||
| * Extra copied files, especially the built-in UCP manifests. | ||
|
|
||
| Preserving runtime parity is a migration requirement, not an optional cleanup item. |
|
|
||
| ## Open Questions | ||
|
|
||
| * Should the initial migration include SBOM generation, or should that remain a follow-up once the core release path is stable? |
There was a problem hiding this comment.
I think that can be a follow-up once the core release path is stable. It should be a priority once the migration is complete, but I don't think it's necessary for the initial migration.
|
This is a very thorough architecture document and should be used as an example/reference for future architecture documents. Well done! Added several comments and some questions. |
DariuszPorowski
changed the title
2 participants
No description provided.