Repository navigation
fix(ci): stop backport workflow from cascading on its own PRs - #2584
Conversation
Two compounding issues caused merging a backport PR to spawn another backport (e.g. #2581 [Backport release-1.2] [Backport release-1.3] ... from #2579): 1. pr-labeler auto-added the `backport` label to any PR whose title started with `[Backport release-X.Y]` (regression introduced in c8ed1c6 when pr-labeler.yaml was first added). korthout/backport- action puts that prefix on every backport PR it creates, so the label was being re-applied to every backport, satisfying the workflow's gate when the backport itself was merged. 2. Even with that fixed, an external labeling bot (dosubot) still re-applies `backport-previous` to backport PRs based on similarity to the parent. That bot is configured at the org level and cannot be controlled from this repo. Drop the `toAdd.add('backport')` line from pr-labeler so the label isn't propagated by us, and gate both backport jobs on `pull_request.base.ref == 'main'` so backport PRs (which target release-X.Y) cannot trigger the workflow regardless of what labels end up on them. Assisted-By: Claude <[email protected]> Signed-off-by: Myasnikov Daniil <[email protected]>
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughThis PR refines the backport workflow by adding branch-safety guards to the GitHub Actions backport and prepare jobs to ensure they only execute when the PR base is main, and removes a redundant backport label from the PR labeler workflow. ChangesBackport Workflow Refinement
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
LGTM — both fixes are necessary and the base.ref guard is the right invariant.
The two roots of the cascade are independent. The pr-labeler self-cascade (prefix [Backport release-X.Y] is exactly what korthout/backport-action emits on its own PRs) exists regardless of any external bot, so dropping that line is required. The base.ref == 'main' guard makes the workflow robust against any future label source — manual, third-party, or otherwise — rather than relying on label hygiene as the safety boundary.
Follow-up (separate PR, not blocking this one): the backport and backport-previous labels do not match the namespaced scheme declared in the header of .github/labels.yml (which says it follows the Kubernetes convention). Upstream uses kind/backport. Worth a small PR that renames in labels.yml (with aliases: to preserve history on already-tagged PRs) and updates every reference in .github/workflows/*.yaml in lockstep.
Andrei Kvapil (kvaps)
left a comment
There was a problem hiding this comment.
LGTM. The two compounding issues are correctly identified and the fix targets both:
backport.yaml: gating both jobs onpull_request.base.ref == 'main'is the right structural lock — backport PRs targetrelease-X.Yso they cannot self-trigger regardless of what label dosubot[bot] (or anything else outside this repo) sticks on them later. This is the layer that actually stops the cascade.pr-labeler.yaml: dropping the auto-add ofbackporton[Backport release-X.Y]titles is the cooperative half — combined with the base-ref gate, even if dosubot or a future automation adds the label back, the workflow still won't fire.
Defense in depth, correct shape. The area/release auto-tagging on backport titles stays, which is what we want for triage.
Ship it.
## What this PR does Expands `docs/release.md` from a ~165-line process-design doc into a ~573-line single source covering both the process design (kept verbatim — mermaid diagrams and the RC/regular/patch numbered walkthroughs) and the operational playbook for cutting a release. New sections added under the existing diagrams: - **What CI does on a tag push** — phase-by-phase walk through `tags.yaml` (`prepare-release`, `generate-changelog`, `update-website-docs`), `pull-requests-release.yaml` (finalize), and `update-releasenotes.yaml` (sync release body). - **Automated patch tag** — `auto-release.yaml`'s nightly behavior. - **Backports** — bot mechanism, recursive-backport regression history (fix #2584), manual fallback, cherry-pick triage include/skip rule, monotonic-counter trap for migration backports. - **Changelogs** — pointer to `agents/changelog.md` plus the recurring failure modes that have shipped in real changelogs, with a verification snippet (chart-bump coverage, range-vs-changelog PR sweep, URL liveness, website PR-author check). - **Release-time fires** — three customer-impacting regressions (v1.3.0 cert-manager ingressClassName, v1.4.0 kubevirt-instancetypes upgrade, v1.4.0 Flux 2.7 → 2.8 readiness deadlock) with "what would have caught this" notes. - **Pre-release verification checklist**, **CI failures release engineers commonly hit**, **Force-retagging** (with open RFC #2677 context), **Splitting a release-blocking bundle PR**, **Cleanup after release**. Example version numbers across the walkthrough switched from the upstream `v0.42.x` legacy placeholders to simple semver-style (`v1.2.0`, `v1.2.1`, `release-1.2`) consistent with semver.org examples and applicable at any point in v1.x. ### Release note ```release-note NONE ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Enhanced release process documentation with clarified CI workflows, comprehensive verification checklists, expanded troubleshooting guidance, and case studies to ensure more reliable releases. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/cozystack/cozystack/pull/2732?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai -->
What this PR does
Fix the cascade where merging a backport PR (e.g. #2579) spawns another backport (e.g. #2581
[Backport release-1.2] [Backport release-1.3] …).Two compounding issues:
pr-labeler.yamlauto-added thebackportlabel to any PR whose title started with[Backport release-X.Y]— exactly the prefixkorthout/backport-actionputs on every backport PR. Introduced inc8ed1c65(CNCF/k8s label conventions). Fixed by dropping thattoAdd.add('backport')line.dosubot[bot]independently re-appliesbackport-previousto backport PRs based on similarity to the parent PR; it cannot be controlled from this repo. Fixed by gating both jobs inbackport.yamlonpull_request.base.ref == 'main', so backport PRs (which targetrelease-X.Y) cannot trigger the workflow regardless of labels.Verified pre-fix behaviour by inspecting the label-event timeline of #2580 (dosubot adds
backport-previous47s after PR open) and the diff ofc8ed1c65addingpr-labeler.yaml.Release note
Summary by CodeRabbit