HYPERFLEET-633 - docs: Define release contract and integration testing strategy with GCP and ROSA teams#120
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds a new HyperFleet Release Contract document defining scope, partner teams (GCP Offering, ROSA), required release artifacts and publication locations, Helm chart distribution plan (temporary ROSA OCI then Konflux-published charts to Quay), Slack notification SLAs, roll-forward recovery with N-1 compatibility and patch timing targets, nightly integration testing via OCI chart injection with a test ownership matrix and recorded gaps/mitigations, plus three rejected alternatives and related links/Jira references. Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 6✅ Passed checks (6 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
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 the current code and only fix it if needed.
Inline comments:
In `@hyperfleet/docs/release-contract.md`:
- Around line 108-111: Remove the contradictory "(exact times TBD)" qualifier
from the header "HyperFleet commits to (exact times TBD):" so the explicit SLAs
in the two bullets ("Producing a patch release within **48 hours** for
Blocker/Critical regressions" and "Producing a patch release within **1 week**
for Major regressions") are the single source of truth; update the header to
"HyperFleet commits to:" (or alternatively remove the bullets and keep the TBD
wording) so the document no longer contains both TBD and explicit times.
- Around line 134-142: The ownership matrix contradicts itself because the "GCP
integration" row is marked as "TBD" while the "Release gate" row requires "All
of the above must pass" before GA; update the document so the gate is operable
by either assigning a concrete owner/schedule to the "GCP integration" row
(replace "TBD (ref: GCP-334)" with the actual owner and cadence) or changing the
"Release gate" text to explicitly exclude items marked TBD (e.g., "All
applicable, non-TBD layers must pass"); edit the rows "GCP integration" and
"Release gate" in the table accordingly to remove the contradiction.
- Around line 56-59: Replace the "GCP Platform Architecture" TBD section with a
concise, concrete architecture description: under the "GCP Platform
Architecture" header enumerate the GCP projects/services used (e.g., VPCs,
GKE/clusters, Cloud SQL/Spanner, Pub/Sub, Cloud Storage, IAM roles), diagram key
integration points with Hyperfleet components, specify auth/identity boundaries
and network/firewall expectations, and list owner responsibilities for testing
and release (who deploys/configures each service and what tests gating
releases). Ensure the section names "GCP Platform Architecture" and any
referenced components (VPC, GKE, Cloud SQL, Pub/Sub, IAM) appear so downstream
teams can map responsibilities and tests.
🪄 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: 923fbbce-26b3-471a-8a72-4d2c5ef875aa
📒 Files selected for processing (1)
hyperfleet/docs/release-contract.md
| **Agreed path**: | ||
|
|
||
| 1. **Short-term (Q2 2026)**: ROSA team sets up a temporary OCI registry to publish HyperFleet Helm charts. This unblocks integration testing immediately. | ||
| 2. **Q2 target**: HyperFleet team publishes charts to an OCI-compliant registry via Conflux as part of the release pipeline, eliminating the temporary workaround and the Git coupling. |
There was a problem hiding this comment.
I think you mean Konflux not Conflux.
| - Start with **nightly runs** against HyperFleet `main` branch, not presubmit jobs | ||
| - Test against the **latest known-good stable version** of the ROSA regional platform (production Maestro version), replacing only the HyperFleet component under test | ||
| - The ROSA team will **temporarily enable OCI chart pushing** so the HyperFleet team can inject PR-built charts into the ROSA deployment pipeline | ||
| - Evaluate **non-blocking presubmit** integration with the HyperFleet release repository as a follow-up |
There was a problem hiding this comment.
Would it be better to add similar prow jobs—like the E2E testing Prow job—as a standard requirement and include them in the release X.Y checklist?
| | Gap | Owning Team | Mitigation | | ||
| |-----|-------------|------------| | ||
| | HyperFleet not yet onboarded to ROSA's pre-merge E2E mechanism | HyperFleet | Onboard to `openshift/release` Prow config + create `quay.io/rrp-dev-ci/` image repos (see onboarding steps above) | | ||
| | Helm chart override (OCI) not yet wired into ROSA CI | ROSA + HyperFleet | Temporary OCI setup by ROSA team (Q2 2026, immediate action); replaced by Conflux Q2 target | |
| | Unit tests | HyperFleet | Each component in isolation | Every PR (presubmit) | | ||
| | Integration tests | HyperFleet | Cross-component API contracts | Every PR (presubmit) | | ||
| | HyperFleet E2E | HyperFleet | HyperFleet stack end-to-end | Nightly (main branch) | | ||
| | ROSA integration | ROSA Team | Full ROSA region + HyperFleet override | Nightly (HyperFleet main) | |
There was a problem hiding this comment.
Who is responsible to update the configuration of breaking changes for nightly integration testing? And how to notify?
|
|
||
| The ROSA regional platform consumes HyperFleet as part of a GitOps deployment pipeline. Each deployment initiates three pipelines: | ||
|
|
||
| ```mermaid |
There was a problem hiding this comment.
When I see you add a mermaid diagram it warms my heart 😆
|
|
||
| Environment configuration is centralized in a `default` file that acts as the bill of materials for Argo CD reconciliation. Component versions, Git revisions, and domain names are defined there and can be overridden per environment. | ||
|
|
||
| ### GCP Platform Architecture |
There was a problem hiding this comment.
Should we include this 🤔 just thinking it might be hard to keep up to date, would be good if we could link to their doc's if they have them instead
|
|
||
| | Artifact | Location | Format | Notes | | ||
| |----------|----------|--------|-------| | ||
| | Container images | `quay.io/openshift-hyperfleet/hyperfleet-{component}:{version}` | OCI image | Built automatically by Prow on GA tag | |
There was a problem hiding this comment.
just leaving a comment for myself as a reminder we need to create a ticket post Konflux onboarding to update all references to the newest image registry
rh-amarin
force-pushed
the
release-contract
branch
from
7538ca9 to
25e7b50
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
hyperfleet/docs/release-contract.md (2)
134-137:⚠️ Potential issue | 🟠 MajorResolve rollback SLA contradiction.
Line 134 says “exact times TBD”, but Lines 136-137 already define explicit timelines. Keep one source of truth so this contract is unambiguous.
Suggested edit
-HyperFleet commits to (exact times TBD): +HyperFleet commits to:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/release-contract.md` around lines 134 - 137, The release-contract currently contains conflicting statements: the heading "HyperFleet commits to (exact times TBD):" contradicts the explicit timelines in the bullets; update the contract so there is a single source of truth by removing or replacing the "(exact times TBD)" text in the header and clarifying that the bullets define the SLA (e.g., change to "HyperFleet commits to the following timelines:"), ensuring the header and the bullet items (the 48-hour and 1-week patch-release commitments) are consistent and unambiguous.
167-177:⚠️ Potential issue | 🟠 MajorMake the release gate operable with currently acknowledged coverage gaps.
Line 167 requires all layers to pass before GA, but Lines 175-177 document known unresolved gaps (notably GCP chart-override limitations and multi-component validation limits). Add an explicit exception/waiver rule, otherwise the gate is not consistently enforceable.
Suggested wording adjustment
-| Release gate | HyperFleet | All of the above must pass | Before GA tag | +| Release gate | HyperFleet | All mandatory, currently implemented layers must pass; unresolved gaps require explicit release waiver from HyperFleet + affected consumer team | Before GA tag |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/release-contract.md` around lines 167 - 177, Update the "Release gate" entry so it is operable despite known gaps by adding an explicit exception/waiver rule that ties to the "Testing Gaps Identified" section: change the Pass criterion text from "All of the above must pass" to include a clause like "All of the above must pass, except for documented, tracked gaps listed under 'Testing Gaps Identified' which may be waived by an approved exception"; add a short waiver process description (who can approve, required tracking ID/issue, and required mitigation timeline) and reference the existing gap items (e.g., the GCP chart-override and multi-component PR testing gaps) so the gate enforcement logic and readers can consistently apply the exception.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@hyperfleet/docs/release-contract.md`:
- Line 127: The sentence "At this point in time (April 26) breaking changes are
not blockers to HyperFleet releases..." contains a hardcoded calendar date that
will go stale; replace the date with a versioned or status-based qualifier
(e.g., "as of release X.Y" or "currently" / "until further notice") and update
the sentence to read something like "Currently, breaking changes are not
blockers to HyperFleet releases; ROSA/GCP teams are not required to maintain
long‑running clusters or migrate data" so the policy remains evergreen—locate
the sentence by searching for the phrase "At this point in time (April 26)" in
release-contract.md and remove the explicit date, substituting a version/status
token.
---
Duplicate comments:
In `@hyperfleet/docs/release-contract.md`:
- Around line 134-137: The release-contract currently contains conflicting
statements: the heading "HyperFleet commits to (exact times TBD):" contradicts
the explicit timelines in the bullets; update the contract so there is a single
source of truth by removing or replacing the "(exact times TBD)" text in the
header and clarifying that the bullets define the SLA (e.g., change to
"HyperFleet commits to the following timelines:"), ensuring the header and the
bullet items (the 48-hour and 1-week patch-release commitments) are consistent
and unambiguous.
- Around line 167-177: Update the "Release gate" entry so it is operable despite
known gaps by adding an explicit exception/waiver rule that ties to the "Testing
Gaps Identified" section: change the Pass criterion text from "All of the above
must pass" to include a clause like "All of the above must pass, except for
documented, tracked gaps listed under 'Testing Gaps Identified' which may be
waived by an approved exception"; add a short waiver process description (who
can approve, required tracking ID/issue, and required mitigation timeline) and
reference the existing gap items (e.g., the GCP chart-override and
multi-component PR testing gaps) so the gate enforcement logic and readers can
consistently apply the exception.
🪄 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: Enterprise
Run ID: 76710a70-aa4f-4b57-8851-ed9092ce43a6
📒 Files selected for processing (1)
hyperfleet/docs/release-contract.md
| | Hotfix / patch release | `#hyperfleet-releases` Slack | Within 2 hours of GA tag | GCP team, ROSA team | | ||
|
|
||
|
|
||
| At this point in time (April 26) breaking changes are not blockers to HyperFleet releases as ROSA/GCP teams do not have to keep long running clusters and migrate data. |
There was a problem hiding this comment.
Remove hardcoded date from normative policy text.
Line 127 embeds a point-in-time statement (April 26) in a rule section. This will go stale and can create policy ambiguity. Prefer a versioned/status-based qualifier instead of a calendar date in the sentence.
Suggested edit
-At this point in time (April 26) breaking changes are not blockers to HyperFleet releases as ROSA/GCP teams do not have to keep long running clusters and migrate data.
+For the current MVP phase, breaking changes are not blockers to HyperFleet releases, since ROSA/GCP teams do not maintain long-running clusters with data migration requirements.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| At this point in time (April 26) breaking changes are not blockers to HyperFleet releases as ROSA/GCP teams do not have to keep long running clusters and migrate data. | |
| For the current MVP phase, breaking changes are not blockers to HyperFleet releases, since ROSA/GCP teams do not maintain long-running clusters with data migration requirements. |
🧰 Tools
🪛 LanguageTool
[grammar] ~127-~127: Use a hyphen to join words.
Context: ... ROSA/GCP teams do not have to keep long running clusters and migrate data. ###...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@hyperfleet/docs/release-contract.md` at line 127, The sentence "At this point
in time (April 26) breaking changes are not blockers to HyperFleet releases..."
contains a hardcoded calendar date that will go stale; replace the date with a
versioned or status-based qualifier (e.g., "as of release X.Y" or "currently" /
"until further notice") and update the sentence to read something like
"Currently, breaking changes are not blockers to HyperFleet releases; ROSA/GCP
teams are not required to maintain long‑running clusters or migrate data" so the
policy remains evergreen—locate the sentence by searching for the phrase "At
this point in time (April 26)" in release-contract.md and remove the explicit
date, substituting a version/status token.
|
/test ci/prow/linkcheck |
|
/test linkcheck |
rh-amarin
force-pushed
the
release-contract
branch
from
25e7b50 to
bf69f00
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
hyperfleet/docs/release-contract.md (2)
80-80:⚠️ Potential issue | 🟠 Major | ⚡ Quick winRemove the hardcoded policy date from the contract statement.
Line 80 uses a fixed date (“April 26”) in normative text, which makes the contract stale/ambiguous over time. Replace it with a status/version-based qualifier (for example, “currently” or “for MVP phase”).
As per coding guidelines, “for documentation PRs in this repo … keep content current” and “write with actionable specificity.”🤖 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 `@hyperfleet/docs/release-contract.md` at line 80, Replace the hardcoded date in the sentence beginning "At this point in time (April 26) ..." with a status/version-based qualifier (e.g., "currently" or "for the MVP phase") so the normative text stays accurate over time; update the sentence to read something like "At this time, breaking changes are not blockers to HyperFleet releases as ROSA/GCP teams..." and ensure the wording is clear and actionably current per the docs guidelines.
87-90:⚠️ Potential issue | 🟠 Major | ⚡ Quick winResolve the SLA contradiction between TBD and explicit deadlines.
Line 87 says exact times are TBD, while Lines 89-90 define concrete times (48 hours / 1 week). Keep one source of truth to make the contract operable.
As per coding guidelines, documentation should be actionable and avoid ambiguous policy text.🤖 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 `@hyperfleet/docs/release-contract.md` around lines 87 - 90, Resolve the SLA contradiction by choosing one source of truth: either remove "exact times TBD" from the header (keep the concrete deadlines in the bullets) or replace the concrete bullets with a statement that specific timelines are TBD; update the phrases "exact times TBD" and the bullet items ("48 hours" / "1 week") in release-contract.md so they are consistent (e.g., change the header to "HyperFleet commits to the following timelines:" if keeping the bullets, or change the bullets to "TBD" if deferring exact timings).
🤖 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 `@hyperfleet/docs/release-contract.md`:
- Around line 135-154: The document lacks an explicit "Trade-offs" section; add
a new "## Trade-offs" heading near the decision content (for example immediately
after the "## Alternatives Considered" block) and list the specific gains,
losses, and risks of the chosen approach (e.g., nightly runs vs presubmit,
skipping consumer-driven contract testing, deferred automated rollout), mapping
each trade-off to the related alternative to satisfy the guideline that both
"Alternatives Considered" and "Trade-offs" are present; ensure the section uses
the same markdown heading style and is concise but covers operational risk,
developer experience, confidence level, and future work implications.
---
Duplicate comments:
In `@hyperfleet/docs/release-contract.md`:
- Line 80: Replace the hardcoded date in the sentence beginning "At this point
in time (April 26) ..." with a status/version-based qualifier (e.g., "currently"
or "for the MVP phase") so the normative text stays accurate over time; update
the sentence to read something like "At this time, breaking changes are not
blockers to HyperFleet releases as ROSA/GCP teams..." and ensure the wording is
clear and actionably current per the docs guidelines.
- Around line 87-90: Resolve the SLA contradiction by choosing one source of
truth: either remove "exact times TBD" from the header (keep the concrete
deadlines in the bullets) or replace the concrete bullets with a statement that
specific timelines are TBD; update the phrases "exact times TBD" and the bullet
items ("48 hours" / "1 week") in release-contract.md so they are consistent
(e.g., change the header to "HyperFleet commits to the following timelines:" if
keeping the bullets, or change the bullets to "TBD" if deferring exact timings).
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: cc6952db-f5d9-41d9-a257-1d90da020544
📒 Files selected for processing (1)
hyperfleet/docs/release-contract.md
| ## Alternatives Considered | ||
|
|
||
| ### 1. Non-blocking Presubmit on HyperFleet Release Repository | ||
|
|
||
| Run the full ROSA integration pipeline as an optional, non-blocking presubmit job triggered on the `hyperfleet-release` repo. | ||
|
|
||
| **Rejected for now**: A ~40-minute+ non-blocking job provides weak signal — developers may ignore it, especially if failures are infrequent. Starting with nightly runs builds confidence in the pipeline before promoting it to presubmit. This remains a **future action**. | ||
|
|
||
| ### 2. Consumer-Driven Contract Testing (Pact-style) | ||
|
|
||
| Define formal API contracts using a consumer-driven contract testing tool (e.g., Pact). ROSA and GCP publish their expectations; HyperFleet CI verifies them on every PR. | ||
|
|
||
| **Rejected for MVP**: The integration surface between HyperFleet and partner teams is primarily at the Helm chart / deployment configuration level, not a REST API contract boundary. Consumer-driven contract testing tools are better suited to service-to-service REST contracts. Helm value schema validation is a lighter-weight alternative to investigate post-MVP. | ||
|
|
||
| ### 3. Automated Rollout to Integration Environments on GA | ||
|
|
||
| Trigger automatic deployment of each HyperFleet GA release to ROSA and GCP integration environments via webhooks. | ||
|
|
||
| **Rejected for MVP**: ROSA's pipeline takes ~40 minutes per run and requires environment-specific configuration overrides. Automating this safely requires tooling (OCI charts via Konflux, pipeline webhooks) not yet in place. Deferred to post-Q2 2026. | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win
Add an explicit “Trade-offs” section for this architectural decision doc.
You have “Alternatives Considered,” but there is no explicit “Trade-offs” section describing gains/losses/risks of the chosen approach. Please add one near the decision content.
As per coding guidelines, “when adding/altering architectural decision content, ensure the document includes required context: ‘Trade-offs’ and ‘Alternatives Considered’ (trade-offs and alternatives go hand-in-hand).”
🤖 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 `@hyperfleet/docs/release-contract.md` around lines 135 - 154, The document
lacks an explicit "Trade-offs" section; add a new "## Trade-offs" heading near
the decision content (for example immediately after the "## Alternatives
Considered" block) and list the specific gains, losses, and risks of the chosen
approach (e.g., nightly runs vs presubmit, skipping consumer-driven contract
testing, deferred automated rollout), mapping each trade-off to the related
alternative to satisfy the guideline that both "Alternatives Considered" and
"Trade-offs" are present; ensure the section uses the same markdown heading
style and is concise but covers operational risk, developer experience,
confidence level, and future work implications.
…n testing strategy
| | Hotfix / patch release | `#hyperfleet-releases` Slack | Within 2 hours of GA tag | GCP team, ROSA team | | ||
|
|
||
|
|
||
| At this point in time (April 26) breaking changes are not blockers to HyperFleet releases as ROSA/GCP teams do not have to keep long running clusters and migrate data. |
There was a problem hiding this comment.
Should we agree on a version, I am thinking up until v3 which is planned for this year, we might introduce breaking changes.
|
|
||
| ## Related Documents | ||
|
|
||
| - [HyperFleet Release Process](../release/hyperfleet-release-process.md) — release cadence, branching, artifacts |
There was a problem hiding this comment.
Do these paths work? I think it should just be release/ instead of ../
| - [Konflux Release Pipeline Design](../release/konflux-release-pipeline-design.md) — build and release pipeline architecture, CEL tag matching, version injection | ||
| - [Helm OCI Distribution Design](../release/helm-oci-distribution-design.md) — how Helm charts are published as OCI artifacts via Konflux | ||
| - [ADR 0014 — Konflux for Container Image Build and Release](../../adrs/0014-konflux-build-and-release.md) | ||
| - [ADR 0016 — Helm OCI Distribution via Konflux](../../adrs/0016-helm-oci-distribution.md) |
There was a problem hiding this comment.
Same as above, think we are jumping back an extra hop to get to adrs
|
|
||
| | Gap | Owning Team | Mitigation | | ||
| |-----|-------------|------------| | ||
| | HyperFleet not yet onboarded to ROSA's pre-merge E2E mechanism | HyperFleet | Onboard to `openshift/release` Prow config + create `quay.io/rrp-dev-ci/` image repos (see onboarding steps above) | |
There was a problem hiding this comment.
What are the onboarding steps referencing here?
| | Helm charts | `quay.io/redhat-services-prod/hyperfleet-tenant/hyperfleet-{component}-chart:{version}` (see [Helm Chart Distribution](#helm-chart-distribution)) | OCI artifact | Published via Konflux `build-helm-chart-oci-ta` task; required for ROSA/Argo CD consumption | | ||
| | Release notes | `hyperfleet-release` repo, `releases/release-X.Y/` | Markdown | Compatibility matrix, breaking changes, upgrade guide | | ||
| | Compatibility matrix | `hyperfleet-release` repo | Markdown table | Maps validated component version combinations | | ||
| | Git tags | Per-component repos + `hyperfleet-release` | `vX.Y.Z` / `release-X.Y` | See [Release Process](hyperfleet-release-process.md) | |
There was a problem hiding this comment.
Tried to navigate to this link but it's missing
See [Release Process](hyperfleet-release-process.md) |
bf69f00 to
5969ca8
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 `@hyperfleet/docs/release-contract.md`:
- Around line 114-117: The "Release gate" table row currently says "All of the
above must pass" but is contradicted by the ROSA/GCP exception; update the table
row text to a single, unambiguous canonical rule (for example: "All mandatory
compatible-version layers must pass") and move the ROSA/GCP exception out of the
gate cell into a separate clarifying note under the table (or rephrase it as
"Compatibility matrix: newer untested ROSA/GCP versions do not block release if
tested compatible versions pass") so the gate definition and the exception do
not conflict; edit the table row entry (the Release gate / HyperFleet cell) and
adjust the following paragraph accordingly to ensure only one authoritative gate
rule exists.
🪄 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: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 2a4c868b-8ebf-4cd3-8bdd-0b9afa13373d
📒 Files selected for processing (1)
hyperfleet/docs/release-contract.md
| | Release gate | HyperFleet | All of the above must pass | Before GA tag | | ||
|
|
||
| **Important**: HyperFleet releases ship with a compatibility matrix for the ROSA/GCP versions tested. If newer ROSA/GCP integration tests fail, that doesn't gate the HyperFleet release as long as it passes the successful ROSA/GCP compatible versions. | ||
|
|
There was a problem hiding this comment.
Make GA gate criteria internally operable and unambiguous.
Line 114 says “all of the above must pass,” but Line 116 introduces an exception for failed newer ROSA/GCP versions. This creates two gate definitions in the same contract. Define one canonical rule in the table row itself (e.g., “all mandatory compatible-version layers must pass”).
🧰 Tools
🪛 LanguageTool
[grammar] ~116-~116: Use a hyphen to join words.
Context: ...ong as it passes the successful ROSA/GCP compatible versions. ### Testing Gaps I...
(QB_NEW_EN_HYPHEN)
🤖 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 `@hyperfleet/docs/release-contract.md` around lines 114 - 117, The "Release
gate" table row currently says "All of the above must pass" but is contradicted
by the ROSA/GCP exception; update the table row text to a single, unambiguous
canonical rule (for example: "All mandatory compatible-version layers must
pass") and move the ROSA/GCP exception out of the gate cell into a separate
clarifying note under the table (or rephrase it as "Compatibility matrix: newer
untested ROSA/GCP versions do not block release if tested compatible versions
pass") so the gate definition and the exception do not conflict; edit the table
row entry (the Release gate / HyperFleet cell) and adjust the following
paragraph accordingly to ensure only one authoritative gate rule exists.
4 participants
https://redhat.atlassian.net/browse/HYPERFLEET-633
This is a first version to have a contract for releasing HyperFleet to be consumed by ROSA and GCP teams