fix(backport-test): opt-out memory test - #23
Open
Yicong-Huang wants to merge 1 commit into
Open
Conversation
|
👋 Thanks for opening this pull request, @Yicong-Huang! It looks like the pull request description doesn't quite follow our template yet:
Filling out the template helps reviewers understand and triage your contribution faster. Please edit the description to complete it. This message will disappear automatically once the template is followed. You can find the template prompts by editing the description, or see CONTRIBUTING.md for the full contribution flow. |
Yicong-Huang
added
release/test-clean
Automated Reviewer SuggestionsBased on the
|
renovate-bot
pushed a commit
to renovate-bot/apache-_-texera
that referenced
this pull request
Jul 27, 2026
…che#6941) ### What changes were proposed in this PR? This PR overhauls the release-backport lifecycle so it stops depending on people remembering. Three problems today, each addressed below. **Problem 1 — Backports are forgotten.** The `release/*` label is added by hand, so authors and committers routinely forget to request a backport, and fixes silently never reach the release branch. _Solution:_ Backporting becomes **opt-out**. A new `backport-auto-label` workflow labels every `fix:` PR into `main` with the configured `release/*` targets and requests review from each branch's **release manager**. `.github/release-branches.yml` is the single source of truth mapping each release branch to its manager and an `actively-supporting` flag (`release/v1.2` → `xuang7`, active; `release/v1.1` → `bobbai00`, inactive), parsed by a stdlib-only helper. Only actively-supporting branches are auto-labeled; an inactive branch stays a valid manual target but isn't offered by default. Remove a label to decline — a removal is remembered via the timeline, so a later edit never silently re-adds it. **Problem 2 — Failed backports are lost.** When a backport conflicts, the only trace is a PR comment that sinks to the bottom and gets forgotten; nobody is on the hook to finish it. And a conflicting cherry-pick still burns the full build matrix. _Solution:_ The pre-merge backport is split into a fast, git-only **apply-check** that gates the expensive build (a conflict is reported in seconds and no longer spins up the stacks), and `backport` is **removed from the Required Checks aggregator** so it's advisory, not a merge gate. Post-merge, `direct-backport-push` classifies each target from that signal: **green** cherry-picks straight to the release branch; **red** (conflict, or applies-but-won't-build) auto-opens a **draft** backport PR `fix(scope, vX.Y): …` on `backport/<PR>-<slug>-<target>`, with the conflicted tree committed, **assigned to the author** with the release manager as reviewer — an actionable task instead of a lost comment. **Problem 3 — Fixes for main-only features get backported anyway.** A fix for a feature that only exists on `main` shouldn't go to the release at all, but it still gets labeled and attempted. _Solution:_ **Automatic feature-absent skip** — before labeling a target (and again on the red path), skip it when every file the PR *modifies* (added files excluded) is absent on that release branch: the feature clearly isn't there. Any ambiguity keeps the label and lets the apply-check decide. For what automation can't catch (new code inside an existing file, or pure judgment), a **`no-backport-needed`** label is a hard manual veto honored end-to-end (auto-label, pre-merge precheck, and post-merge push). Note: a red apply-check now shows as a (non-blocking) red check on the PR — the intended "this needs a manual backport" signal, not a merge blocker. ### Any related issues, documentation, discussions? Resolves apache#6940. ### How was this PR tested? Static: `actionlint` on all workflows; YAML parses; every `github-script` block passes `node --check`; `bash -n` on the scripts; unit-checked the parser, branch-slug derivation, `fix(scope, vX.Y)` title injection, and the feature-absent git guard. End-to-end on a fork test harness ([`Yicong-Huang/texera`](https://github.com/Yicong-Huang/texera), throwaway `release/test-clean` + `release/test-conflict` branches, docs-only fixes to skip the heavy build): | Scenario | Result | Evidence | | --- | --- | --- | | `fix:` PR into main → auto-labeled with both targets | ✅ | [PR apache#19](Yicong-Huang#19) | | apply-check: green on clean target, red on conflicting one | ✅ | [run](https://github.com/Yicong-Huang/texera/actions/runs/30303217100) | | red apply-check does **not** block merge (Required Checks green) | ✅ | [run](https://github.com/Yicong-Huang/texera/actions/runs/30303217100) | | green target → cherry-picked to the release branch (author preserved) | ✅ | [commit `ef1df63`](Yicong-Huang@ef1df63) · [run](https://github.com/Yicong-Huang/texera/actions/runs/30303765765) | | red target → draft PR `fix(scope, vX.Y): …`, conflict markers committed, assigned to author | ✅ | [PR apache#22](Yicong-Huang#22) | | fix touching only files absent on the release branch → not labeled | ✅ | [PR apache#20](Yicong-Huang#20) | | `no-backport-needed` → all backport work vetoed | ✅ | [PR apache#21](Yicong-Huang#21) | | remove a label then edit → not re-added (opt-out remembered) | ✅ | [PR apache#23](Yicong-Huang#23) | Not exercised on the fork: the request-review success path (the test manager was the PR author, so it correctly took the skip branch) and a full heavy-build green path (docs-only by design). ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 4.8) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
S4 edited to retrigger auto-label