chore(ci): namespace the backport labels under kind/ - #3433
Conversation
The labels.yml header declares that names follow the Kubernetes scheme, but backport and backport-previous were top-level, violating it. Rename them to kind/backport and kind/backport-previous, grouped under the kind/ section, and carry the old names as aliases so EndBug/label-sync renames in place without dropping history on already-tagged issues and PRs. Update the label literals in backport.yaml in lockstep (the if filter and the label-detection script). pr-labeler.yaml's 'backport' entry is a Conventional-Commit scope-to-area mapping, not a label reference, so it is left unchanged. The top-level release label is a functional trigger keyed by name in several workflows; renaming it is a wider cross-workflow change out of scope here, so it is left as-is intentionally. Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
📝 WalkthroughWalkthroughBackport labels are moved into the ChangesBackport label namespace
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).github/labels.ymlTraceback (most recent call last): .github/workflows/backport.yamlTraceback (most recent call last): .github/workflows/stale.yamlTraceback (most recent call last): 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 |
The initial rename missed several literal consumers of the old label names beyond labels.yml and backport.yaml: - stale.yaml exempt-pr-labels still listed backport,backport-previous. actions/stale matches label names exactly and does not resolve label-sync aliases, so after the rename a kind/backport PR would lose its stale exemption and get auto-closed after inactivity. This is the one behavioural regression; the rest are documentation drift. - PULL_REQUEST_TEMPLATE.md told contributors to apply the backport label. - release.md label-target table and the gh pr list --search commands referenced the old names (the searches would silently return nothing). - contributing.md claimed a backport label is auto-applied on the [Backport] prefix; pr-labeler only adds area/release, so the line was already stale and is corrected while renaming. Historical narrative in release.md and the backport scope-to-area doc rows (a Conventional-Commit scope, not the label) are left as-is. Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 @.github/PULL_REQUEST_TEMPLATE.md:
- Line 11: Update the label guidance in the pull request template to distinguish
the release lines: document that kind/backport targets the current release line
and kind/backport-previous targets the previous release line, replacing the
ambiguous “previous version” wording.
In `@docs/release.md`:
- Line 312: Update the gh pr list search query in the backport loop to use
comma-separated OR label filtering, so it matches PRs with either kind/backport
or kind/backport-previous while preserving the existing merged-date constraint.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 208caf38-e080-4f44-a83e-b9c2a60a34af
📒 Files selected for processing (6)
.github/PULL_REQUEST_TEMPLATE.md.github/labels.yml.github/workflows/backport.yaml.github/workflows/stale.yamldocs/agents/contributing.mddocs/release.md
| - If it's a work in progress, consider creating this PR as a draft. | ||
| - Don't hesistate to ask for opinion and review in the community chats, even if it's still a draft. | ||
| - Add the label `backport` if it's a bugfix that needs to be backported to a previous version. | ||
| - Add the label `kind/backport` if it's a bugfix that needs to be backported to a previous version. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Clarify which release line each label targets. Line 11 describes kind/backport as applying to a “previous version,” but that label targets the current release line; kind/backport-previous targets the previous release line. Please document both choices.
Proposed wording
-- Add the label `kind/backport` if it's a bugfix that needs to be backported to a previous version.
+- Add `kind/backport` for the current release line, or `kind/backport-previous` for the previous release line.📝 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.
| - Add the label `kind/backport` if it's a bugfix that needs to be backported to a previous version. | |
| - Add `kind/backport` for the current release line, or `kind/backport-previous` for the previous release line. |
🤖 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 @.github/PULL_REQUEST_TEMPLATE.md at line 11, Update the label guidance in
the pull request template to distinguish the release lines: document that
kind/backport targets the current release line and kind/backport-previous
targets the previous release line, replacing the ambiguous “previous version”
wording.
|
|
||
| ```bash | ||
| for n in $(gh pr list --search "label:backport label:backport-previous merged:>=2026-01-01" --json number --jq '.[].number'); do | ||
| for n in $(gh pr list --search "label:kind/backport label:kind/backport-previous merged:>=2026-01-01" --json number --jq '.[].number'); do |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Repository docs/release.md around target lines:"
sed -n '295,325p' docs/release.md | nl -ba -v295
echo
echo "Check gh availability and help/version:"
(command -v gh >/dev/null 2>&1 && gh --version | head -n5) || true
echo
echo "Search for gh pr search label usage docs release:"
rg -n "gh pr list|label:kind/backport|backport-previous" docs/release.md || true
echo
echo "Parse label qualifiers in target search using python:"
python3 - <<'PY'
import re
s = 'label:kind/backport label:kind/backport-previous merged:>=2026-01-01'
fields = s.split()
labels = []
other = []
for f in fields:
m = re.match(r'^label:"?([^"]+)"?$', f)
if m:
labels.append(m.group(1))
else:
other.append(f)
print("fields=", fields)
print("labels_order=", labels)
print("non_label_fields=", other)
print("seems_AND_behavior_claim: repeated label qualifiers are separate terms so only PRs matching both labels and merged condition are included.")
def satisfies(query, pr):
terms = query.split()
for term in terms:
m = re.match(r'^label:"?([^"]*)"?$', term)
if m:
val = m.group(1)
if val not in pr.get("labels", []):
return False
else:
# date not evaluated; ignore for label-only cases
if term != "merged:>=2026-01-01":
return False
return True
cases = [
{"labels": []},
{"labels": ["kind/backport"]},
{"labels": ["kind/backport-previous"]},
{"labels": ["kind/backport", "kind/backport-previous"]},
]
for pr in cases:
print(pr, "query_or_label_terms_includes_one_or_other_or_both=False?" not satisfies(s, pr))
PYRepository: cozystack/cozystack
Length of output: 245
🌐 Web query:
GitHub CLI gh pr list search label comma OR documentation repeated label filters AND
💡 Result:
When using the GitHub CLI (gh pr list), the --label flag applies "AND" logic when multiple labels are specified [1][2]. If you provide multiple --label flags, the command will only return pull requests that contain all of the specified labels [1][3][4]. For example, to list only pull requests that have both the "bug" and "priority 1" labels, you would use: gh pr list --label bug --label "priority 1" Historical context and notes: - Breaking Change: Older versions of the GitHub CLI previously used "OR" logic for the --label flag [2]. This was changed to "AND" logic to align with the behavior of the GitHub web interface [2]. - Comma Separation: While some users may attempt to use comma-separated values (e.g., --label "label1,label2"), the standard and documented way to filter by multiple labels is to repeat the --label flag for each individual label [1][5][4]. - Advanced Filtering: If you require more complex boolean logic (such as "OR" filtering or excluding specific labels), you can use the --search flag [6][7]. The --search flag allows you to pass raw GitHub search query syntax directly, such as -label:bug to exclude a label [6][7].
Citations:
- 1: https://cli.github.com/manual/gh_pr_list
- 2: BREAKING: lookup all issue/PR labels with "AND" instead of "OR" cli/cli#3295
- 3: https://man.archlinux.org/man/gh-pr-list.1.en
- 4: https://www.gsp.com/cgi-bin/man.cgi?topic=GH-PR-LIST
- 5: https://manpages.debian.org/trixie/gh/gh-pr-list.1.en.html
- 6: https://cli.github.com/manual/gh_search_prs
- 7: How to list pull requests with exclude label cli/cli#4142
🌐 Web query:
GitHub Search pull requests label query comma separated values OR label:"kind backport" quoted
💡 Result:
To search for pull requests with a specific label on GitHub, you use the label qualifier [1][2]. When a label name contains spaces or special characters (such as a slash), you must wrap the label name in quotation marks [1][3]. For a label such as "kind backport", the search query would be: label:"kind backport" If you need to search for multiple labels using "OR" logic (e.g., matching pull requests that have either "kind backport" or another label), you can use a comma-separated list of labels [1][2][4]. For example: label:"kind backport","other label" Key points for GitHub search syntax regarding labels: 1. Basic Search: label:"your label name" [1][2]. 2. Logical OR: label:"label1","label2" [2][4]. 3. Logical AND: To require multiple labels simultaneously, repeat the label qualifier for each, such as label:"label1" label:"label2" [1][2]. 4. Case Insensitivity: GitHub search is not case sensitive [1][3]. 5. Quoting: Quotation marks are required for any label containing spaces [1][3]. These queries work in the main GitHub search bar, as well as with the GitHub CLI (e.g., gh pr list --search 'label:"kind backport"') [5][2].
Citations:
- 1: https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests
- 2: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/filtering-and-searching-issues-and-pull-requests
- 3: https://github.com/github/docs/blob/main/content/search-github/searching-on-github/searching-issues-and-pull-requests.md
- 4: https://github.blog/changelog/2021-08-01-search-issues-by-label-using-logical-or/
- 5: https://cli.github.com/manual/gh_search_prs
Use OR label filtering for backport PRs. The current label:kind/backport label:kind/backport-previous query requires both labels; use a comma-separated filter for PRs with either backport label.
Proposed command
-for n in $(gh pr list --search "label:kind/backport label:kind/backport-previous merged:>=2026-01-01" --json number --jq '.[].number'); do
+for n in $(gh pr list --search 'label:"kind/backport","kind/backport-previous" merged:>=2026-01-01' --json number --jq '.[].number'); do📝 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.
| for n in $(gh pr list --search "label:kind/backport label:kind/backport-previous merged:>=2026-01-01" --json number --jq '.[].number'); do | |
| for n in $(gh pr list --search 'label:"kind/backport","kind/backport-previous" merged:>=2026-01-01' --json number --jq '.[].number'); do |
🤖 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 `@docs/release.md` at line 312, Update the gh pr list search query in the
backport loop to use comma-separated OR label filtering, so it matches PRs with
either kind/backport or kind/backport-previous while preserving the existing
merged-date constraint.
Source: MCP tools
myasnikovdaniil
left a comment
There was a problem hiding this comment.
NOT LGTM — the rename retargets the backport trigger onto label names that the org-level dosubot does not apply, and that bot is the sole applier on a measurable share of real backports.
Business context: align the two backport labels with the namespaced Kubernetes label convention that .github/labels.yml's own header declares, closing #2585.
Blockers
B1: dosubot still applies the legacy label names, so the backport bot stops firing for them
File: .github/workflows/backport.yaml:22-24 and :43-44
Issue: the prepare gate now matches kind/backport / kind/backport-previous only. The aliases: in labels.yml migrate labels already attached to issues and PRs, but they do not change what an external bot applies going forward — and the dominant applier of these two labels is an integration this repository does not configure.
Evidence:
dosubot[bot]accounts for 130backport/backport-previouslabel applications across this repository's label-event history, second only to a maintainer at 137. Most recent: 2026-07-28 on #3473, #3474 and #3478, plusbackport-previouson #3472.- On #3409 (
base=main, merged) the label timeline showsbackportapplied bydosubot[bot]at2026-07-21T21:23:47Zand by no one else, after which the backport bot opened #3442[Backport release-1.6] .... The same chain runs #3282 → #3326. The bot-applied label is load-bearing, not decoration. - #2504 did not disable Dosu. Its description states it landed native workflows "ahead of disabling the Dosu app on this repo", and the three files it touched (
labels.yml,pr-size.yaml,stale.yaml) are all additive — the app is configured outside this repository, so nothing in-repo could have disabled it. It is still active:dosubot[bot]appliedstaleon 2026-08-01 and 2026-08-02 (#1437, #1604, #2000, #2372 among others), a name that exists inlabels.ymlonly as an alias oflifecycle/stale.POST /repos/{owner}/{repo}/issues/{number}/labelscreates a label that does not exist, so the bot re-materialises retired names and the weeklylabels.yamlschedule merges them back afterwards (last run 2026-08-03T05:26Z, success).docs/changelogs/v1.4.0.md:268describing the integration as removed overstates what actually merged. - #2504 is also where the assumption entered: its audit concluded "zero hard dependencies on Dosu's outputs —
backport*is human-applied". That grep looked for workflow consumers of the labels and never checked who writes them, so it missed the one real dependency. This PR inherits the same assumption.
Impact: after merge, a main-targeted PR whose backport label comes from the bot carries a freshly re-created top-level backport label. The prepare gate does not match, the job is skipped, and no backport PR is created — no failure, no annotation, nothing in any log. The earliest fixup is the next weekly label sync, by which point the closed event has passed and cannot be replayed. Against the last five weeks of traffic that is roughly a dozen main-targeted PRs.
Fix: accept both spellings in the if: and in the detection script for as long as the bot can write the legacy names:
contains(github.event.pull_request.labels.*.name, 'kind/backport') ||
contains(github.event.pull_request.labels.*.name, 'backport') ||const isBackport = labels.includes('kind/backport') || labels.includes('backport');Sequencing this behind a Dosu-side rename instead is possible but not free: disabling or reconfiguring the app removes the backport labeling that currently drives the pipeline, so a replacement has to land first. #2504 also deferred its lgtm decision to "7 days post-Dosu-disable", a clock that never started for the same reason.
Non-blocking follow-ups
docs/release.md:312— repeatedlabel:qualifiers are AND, not OR, so the loop inspects a subset of the intended PRs. Measured against the current labels:label:backport is:mergedreturns 321,label:backport-previous is:mergedreturns 79, both qualifiers in one query return 60, and the comma OR form returns 340. The defect predates this PR, but the line is being rewritten by it.--search 'label:"kind/backport","kind/backport-previous" merged:>=...'fixes it..github/PULL_REQUEST_TEMPLATE.md:11names onlykind/backportwhile describing it as a backport "to a previous version", which is what the other label means.docs/release.md:284-286mapskind/backporttorelease-X.Y(current) andkind/backport-previoustorelease-X.(Y-1). Worth naming both..github/labels.yml:81-82— the comment about having no upstream Kubernetes equivalent sits abovekind/backport, which does have one. Move it abovekind/backport-previous, the label it actually describes.- Naming, for the record: in the Kubernetes scheme
kind/denotes the type of an issue or PR, butkind/backport-previousencodes a target release line, which is a routing dimension rather than a type. #2585 offeredbackport/currentplusbackport/previousas the alternative; that models the dimension directly and extends to a third supported release line without a second rename cycle. Since #2585 asked for the decision to be captured, this is the part worth arguing explicitly in the description. - Out of scope, noted only because the file is open:
full-e2e,prebake,upgrade-e2eanddebug(pull-requests.yaml:640,:676,:774) are live labels used as workflow triggers but absent fromlabels.yml, as are the GitHub defaultsinvalidandwontfix. Withdelete-other-labels: falsethey persist unmanaged.
| (github.event.action == 'labeled' && (github.event.label.name == 'backport' || github.event.label.name == 'backport-previous')) | ||
| contains(github.event.pull_request.labels.*.name, 'kind/backport') || | ||
| contains(github.event.pull_request.labels.*.name, 'kind/backport-previous') || | ||
| (github.event.action == 'labeled' && (github.event.label.name == 'kind/backport' || github.event.label.name == 'kind/backport-previous')) |
There was a problem hiding this comment.
This gate is the blocker (B1 in the review body). dosubot[bot] writes the legacy backport / backport-previous names — 130 applications historically, most recently 2026-07-28 — and on #3409 it was the only actor that applied backport before the bot opened #3442. Dosu is configured outside this repository (#2504 landed native workflows "ahead of disabling the Dosu app" but nothing disabled it, and the bot was still writing stale on 2026-08-02), so the rename cannot reach it. After merge, a bot-labeled main PR re-creates the top-level backport label, this if: does not match, and the backport is silently never created.
Accepting both spellings here and at line 43-44 keeps the pipeline intact while the label name is namespaced:
contains(github.event.pull_request.labels.*.name, 'kind/backport') ||
contains(github.event.pull_request.labels.*.name, 'backport') ||
contains(github.event.pull_request.labels.*.name, 'kind/backport-previous') ||
contains(github.event.pull_request.labels.*.name, 'backport-previous') |||
|
||
| ```bash | ||
| for n in $(gh pr list --search "label:backport label:backport-previous merged:>=2026-01-01" --json number --jq '.[].number'); do | ||
| for n in $(gh pr list --search "label:kind/backport label:kind/backport-previous merged:>=2026-01-01" --json number --jq '.[].number'); do |
There was a problem hiding this comment.
Two label: qualifiers in one query are ANDed, so this loop walks only the PRs carrying both labels. Measured against the current labels: label:backport is:merged returns 321, label:backport-previous is:merged returns 79, both together return 60, and the comma OR form returns 340. The defect predates the rename, but this line is being rewritten anyway, so it is a free fix:
for n in $(gh pr list --search 'label:"kind/backport","kind/backport-previous" merged:>=2026-01-01' --json number --jq '.[].number'); do| - If it's a work in progress, consider creating this PR as a draft. | ||
| - Don't hesistate to ask for opinion and review in the community chats, even if it's still a draft. | ||
| - Add the label `backport` if it's a bugfix that needs to be backported to a previous version. | ||
| - Add the label `kind/backport` if it's a bugfix that needs to be backported to a previous version. |
There was a problem hiding this comment.
This now names only kind/backport while describing it as a backport "to a previous version" — which is what kind/backport-previous means. Per the table at docs/release.md:284-286, kind/backport targets release-X.Y (the current line) and kind/backport-previous targets release-X.(Y-1). Naming both, with the release line each one selects, removes the ambiguity the old wording already had.
| color: 'e11d21' | ||
| description: Indicates the change introduces a breaking API or behaviour change | ||
|
|
||
| # kind/backport-previous has no upstream Kubernetes equivalent (k8s has no |
There was a problem hiding this comment.
This comment describes kind/backport-previous but sits above kind/backport, which does have an upstream Kubernetes equivalent (kind/backport in kubernetes/test-infra). Moving it directly above kind/backport-previous puts the rationale on the label it belongs to.
|
Taken over in #3844, with your commits replayed on current main rather than rewritten. What was blocking it is fixed there: the gate now accepts both the namespaced and the legacy spellings, because One thing appeared after you opened this: #3569 added a concurrency guard that enumerates the two legacy label names, so the rename would have quietly stopped it covering the case it exists for. That is extended in #3844 too. Closing this one in favour of it. The rename itself is yours. |
What this PR does
Aligns the backport labels with the namespaced label convention the
.github/labels.ymlheader declares (the Kubernetes scheme:kind/,area/,priority/, ...).backportandbackport-previouswere the only labels left top-level, violating that header.Renames them to
kind/backportandkind/backport-previous, moves them into thekind/section, and carries the old names asaliases:soEndBug/label-syncrenames them in place without dropping history on already-tagged issues and PRs. Upstream Kubernetes useskind/backportfor the same meaning;kind/backport-previoushas no upstream equivalent (k8s has no two-release-line model) but stays underkind/per the file convention.Updates the label literals in
.github/workflows/backport.yamlin lockstep: thepreparejob'sif:filter and the label-detection script. This is the only workflow that consumes these labels.pr-labeler.yaml'sbackportentry is a Conventional-Commit scope-to-area mapping (fix(backport): ...→area/release), not a label reference, so it is left unchanged.The top-level
releaselabel was raised in #2585 as an open question. It is a functional trigger keyed by literal name across several workflows (pull-requests.yaml,pull-requests-release.yaml, the backport gating), so renaming it is a wider cross-workflow change out of scope for this label-convention alignment. Left as-is intentionally.The
labels.ymlschema validator (description length, hex color, unique names, alias/name collisions) was run locally against the result and passes.Closes #2585.
Downstream repositories
Walked the trigger map against the diff. Changed paths are
.github/labels.ymland.github/workflows/backport.yaml; no downstream repository triggers on either.Release note
Summary by CodeRabbit
Workflow Improvements
kind/category.Documentation