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.
There was a problem hiding this comment.
Do we limit ourselves by choosing golang for this tool? Python is often the standard for libraries around devops operations.
There was a problem hiding this comment.
I don't think we limit ourselves by choosing golang for this tool - and I think it fits well with the skillset of the team.
| * 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
|
related: radius-project/radius#11447 |
|
|
||
| ## User Experience (if applicable) | ||
|
|
||
| The primary user experience change is for maintainers and release engineers rather than Radius end users. The release interaction model becomes tag-first instead of `versions.yaml`-first. A maintainer either pushes a release tag directly or uses a small helper workflow to create the tag and ensure the release branch exists. |
There was a problem hiding this comment.
The original motivation for versions.yaml was to support multiple "supported" versions. Will we replace it with some other mechanism for tracking supported versions?
| ```text | ||
| Workflow: Create Release Tag | ||
| version: 0.56.0-rc1 | ||
| ref: release/0.56 |
There was a problem hiding this comment.
if we can do everything in GitHub actions, I think that would be better.
| * Changelog generation is inconsistent between RC and final releases. | ||
| * The existing workflow structure uses multiple matrix and helper jobs where one release-oriented tool can express the same intent more directly. | ||
|
|
||
| These issues are not isolated bugs. They are symptoms of a release system whose complexity now exceeds the complexity of the product changes it is meant to ship. |
|
|
||
| `versions.yaml` remains in the repository as documentation of supported versions and channels, but it is demoted from automation trigger to post-release metadata. A successful release can open an automated pull request to update the file rather than making the file control the release. | ||
|
|
||
| This is a cleaner separation of concerns and reduces failure modes caused by mixing documentation intent with automation control. |
| The repository adds a single `.goreleaser.yaml` file that defines: | ||
|
|
||
| * Six primary Go builds from the main module: `rad`, `ucpd`, `applications-rp`, `dynamic-rp`, `controller`, and `pre-upgrade`. | ||
| * CLI archive creation for `rad` with Windows ZIP output and tarballs for other operating systems. |
There was a problem hiding this comment.
This would be an added benefit of GoReleaser, correct? I believe today's release process doesn't allow for users to install past versions of the rad cli, so I'd recommend adding this as a "Pro" for option 3.
| * monitor the post-release coordination workflow, | ||
| * run release verification, | ||
| * handle any downstream approvals that remain intentionally separate. | ||
|
|
There was a problem hiding this comment.
to be fair, this is basically the same as what we have today. the release documentation is intentionally verbose to disambiguate
| * Encourage the same prefixes in commits when practical. | ||
| * Keep changelog fallback groups so imperfect commit hygiene does not block releases. | ||
|
|
||
| Release notes in the docs tree can still be attached or referenced from the GitHub Release, but the release creation path becomes a single code path for both RC and final releases. |
There was a problem hiding this comment.
Does this mean release notes are added to the release post-creation of the release vs in a PR as they are now?
|
|
||
| #### Makefile reduction | ||
|
|
||
| The Makefile should stop being the source of truth for release publishing. Release-specific includes such as binary build, docker build, version propagation, and artifact management should be removed once the GoReleaser path is validated. |
There was a problem hiding this comment.
Developers currently use those make targets to push builds for customer testing or shared development, does GoReleaser support non release build/push?
| * Post-release coordination failure: the release remains published, but follow-on jobs surface actionable failures with clear workflow summaries. | ||
| * External-dispatch failure: downstream repository dispatch and monitoring steps report explicit failure rather than relying on manual polling. | ||
|
|
||
| The workflow summary should provide a concise status report so release engineers can see which stage failed without reading every job log in detail. |
There was a problem hiding this comment.
one of the most pressing issues is non-retryability or idempotency of release actions. does GoReleaser help here? its rarely clear to engineers what can be retried and what needs a new rc/ version.
There was a problem hiding this comment.
+1 how does GoReleaser typically handle errors in a release process? does it restart from the beginning or does the release engineer need to do anything to continue
| * Which image architecture, if any, failed? | ||
| * Was the GitHub Release created? | ||
| * Did downstream coordination complete or fail? | ||
|
|
|
|
||
| * Should the initial migration include SBOM generation, or should that remain a follow-up once the core release path is stable? | ||
| * Should conventional-commit enforcement happen on commits, PR titles, or both? | ||
| * Should the test-module binaries (`testrp`, `magpiego`) receive their own GoReleaser configuration immediately or remain on separate build logic for now? |
There was a problem hiding this comment.
Is there any reason to not migrate these test-module binaries immediately?
kachawla
left a comment
kachawla
left a comment
There was a problem hiding this comment.
Does this change anything with the way we handle release bicep-types-aws repo?
9 participants
No description provided.