RFC 0020: Two-Phase Release Workflow#178
Open
Boomatang wants to merge 3 commits into
Open
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughAdds RFC 0020 defining a two-phase GitHub release workflow for Kuadrant component repositories. It covers pre-release and release responsibilities, ChangesTwo-Phase Release Workflow RFC
Estimated code review effort: 2 (Simple) | ~15 minutes Sequence Diagram(s)Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@rfcs/0000-two-phase-release-workflow.md`:
- Around line 134-135: Update the cross-RFC reference in
rfcs/0000-two-phase-release-workflow.md so it consistently points to the RFC
specified by the PR objective (change the citation that currently references RFC
0015 to RFC 0018), and make the same correction for the other occurrence noted
(lines around 469-470); ensure both the numeric RFC ID, link URL and title text
match RFC 0018 so implementers have a single normative source.
- Around line 5-6: The RFC currently uses placeholder tracking links
"Kuadrant/architecture#0000" for both the "RFC PR" and "Issue tracking" entries;
replace those placeholders with the actual pull request and issue references for
this proposal so both lines under the header point to the real PR and issue
(update the two occurrences of Kuadrant/architecture#0000).
- Around line 141-144: The “No phantom releases.” guarantee conflicts with the
phase order that creates release tags before building artifacts (see the “Tests
before artifacts.” / phase ordering in the two-phase release workflow), so
either relax the guarantee text or change the normative flow: update the “No
phantom releases.” paragraph to qualify the guarantee (e.g., “No phantom GitHub
Releases will be left if all rollback steps run; tags/images may require cleanup
on partial failures”), OR move tag/publish steps to occur after artifact build
and add explicit rollback steps that delete pushed tags and container images on
failure; reference and update the headings/sections titled “No phantom
releases.” and “Tests before artifacts.” and any flow descriptions that mention
creating tags/images before artifacts to keep wording and behavior consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: aa633d1b-837c-49e0-98cd-dc41c74f122f
📒 Files selected for processing (1)
rfcs/0000-two-phase-release-workflow.md
guicassolato
reviewed
Jun 8, 2026
This RFC introduces the concept of a two-phase release workflow base off the security policy of no writes to a release branch, but also address a number of issue faced while releasing kuadrant 1.5.0 Signed-off-by: Jim Fitzpatrick <jfitzpat@redhat.com>
Boomatang
force-pushed
the
release_process
branch
from
June 19, 2026 11:43
fd02643 to
2babc0b
Compare
Boomatang
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
rfcs/0020-two-phase-release-workflow.md (2)
113-113: 💤 Low valueMinor grammar and style improvements for clarity.
Several sentences can be tightened for clarity:
- Line 113: Add a comma for readability: "The version
0.0.0is a sentinel value, meaning 'targets latest / under active development.'"- Line 213: The phrase "On release branches" repeats twice in consecutive sentences. Consider combining: "On release branches, the version and all dependency versions must not be
0.0.0— they must be concrete released versions."- Line 364: Add comma before "but": "...could reduce this burden**,** but is out of scope..."
- Line 430: Remove hyphen from adverb: "loosely coupled workflows" (not "loosely-coupled").
- Line 461: Add comma before "but": "...is actively being designed**,** but is independent..."
Also applies to: 213-213, 364-364, 430-430, 461-461
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@rfcs/0020-two-phase-release-workflow.md` at line 113, Fix the following grammar and style issues in the RFC document: add a comma after "sentinel value" on line 113 to read "is a sentinel value, meaning"; on line 213, combine the two consecutive sentences that both start with "On release branches" into a single sentence to avoid repetition; on line 364, add a comma before "but" in the phrase "could reduce this burden, but is out of scope"; on line 430, remove the hyphen from "loosely-coupled" to make it "loosely coupled"; and on line 461, add a comma before "but" in the phrase "is actively being designed, but is independent". These changes improve readability and consistency of style throughout the document.Source: Linters/SAST tools
262-266: 💤 Low valueAdd language identifier to the code block.
The flowchart at line 264 is a fenced code block without a language identifier. For clarity and to satisfy Markdown linting, please specify a language (e.g.,
mermaid,text, orplaintext) or use an alternative notation (e.g., a list).Suggested fix
-``` +```text read-version → smoke-tests → tag → build artifacts → create-release -``` +```🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@rfcs/0020-two-phase-release-workflow.md` around lines 262 - 266, The fenced code block containing the job flow description (read-version → smoke-tests → tag → build artifacts → create-release) is missing a language identifier on the opening fence. Add a language identifier such as `text` or `plaintext` to the opening triple backticks of this code block to satisfy Markdown linting requirements and improve clarity. For example, change the opening fence from triple backticks alone to triple backticks followed by the language identifier.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@rfcs/0020-two-phase-release-workflow.md`:
- Around line 141-157: The "no phantom releases" guarantee in the principles
section overstates the scope by claiming "The release either fully succeeds or
does not happen," but the phase ordering documented later (which pushes git tags
before building artifacts) allows for partial failures where tags are created
even if subsequent artifact builds fail. To resolve this inconsistency, either
revise the guarantee wording in the "no phantom releases" bullet to explicitly
acknowledge that while no GitHub Release is created on failure, git tags and
partially published images may require manual cleanup, or restructure the phase
ordering to ensure all artifacts are built and validated before any tags are
pushed to the repository, with explicit rollback procedures for partial
failures.
- Around line 130-137: The release branch naming section contains a reference to
RFC 0015 for the release branch naming convention, but the PR objectives
indicate this should align with RFC 0018 instead. Verify which RFC number is the
correct authoritative source for release branch naming, then update the inline
link reference to the correct RFC in the "Release branch naming" section header
explanation, and also update any corresponding references to this RFC elsewhere
in the document (around the area that discusses release branch naming
principles) to ensure all citations point to the same authoritative RFC.
---
Nitpick comments:
In `@rfcs/0020-two-phase-release-workflow.md`:
- Line 113: Fix the following grammar and style issues in the RFC document: add
a comma after "sentinel value" on line 113 to read "is a sentinel value,
meaning"; on line 213, combine the two consecutive sentences that both start
with "On release branches" into a single sentence to avoid repetition; on line
364, add a comma before "but" in the phrase "could reduce this burden, but is
out of scope"; on line 430, remove the hyphen from "loosely-coupled" to make it
"loosely coupled"; and on line 461, add a comma before "but" in the phrase "is
actively being designed, but is independent". These changes improve readability
and consistency of style throughout the document.
- Around line 262-266: The fenced code block containing the job flow description
(read-version → smoke-tests → tag → build artifacts → create-release) is missing
a language identifier on the opening fence. Add a language identifier such as
`text` or `plaintext` to the opening triple backticks of this code block to
satisfy Markdown linting requirements and improve clarity. For example, change
the opening fence from triple backticks alone to triple backticks followed by
the language identifier.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b1a7e049-c219-4fd5-87ef-b70381c70530
📒 Files selected for processing (1)
rfcs/0020-two-phase-release-workflow.md
averevki
self-requested a review
June 23, 2026 08:57
averevki
reviewed
Jun 23, 2026
Signed-off-by: Jim Fitzpatrick <jfitzpat@redhat.com>
mikenairn
reviewed
Jun 30, 2026
Open
6 tasks
Signed-off-by: Jim Fitzpatrick <jfitzpat@redhat.com>
This was referenced Jul 10, 2026
13 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
4 participants
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.
Summary
This RFC introduces a two-phase release workflow model for all Kuadrant component repositories, evolving the process described in RFC 0008.
The v1.5.0 release exposed systemic failures in the single-workflow release model: false success reporting, hidden workflow chains, silent downstream failures, policy violations from direct commits to protected branches, and missing dependency gating. These all stem from conflating code changes with artifact publishing in a single workflow.
What this RFC proposes
Every release is split into two distinct GitHub Actions workflows:
A human review gate (PR approval) sits between the two phases, satisfying Red Hat's Segregation of Duties policy and giving CI an opportunity to validate the release branch before any artifacts are published.
A
release.yamlfile is added to every component repository as the machine-readable source of truth for version and dependency information. A version gate CI check uses this file to prevent operators from releasing before their operand dependencies have published GitHub Releases.Key guarantees
Relationship to existing RFCs
release-X.Ybranch naming convention defined in RFC 0018 (Standardize Release Branch Naming)Summary by CodeRabbit