The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-6941-9c6e8acfb9060600f7d6ff43a8025161cbdb25d6 has succeeded. Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).
Head commit for run: 1540a81949dc4111b633935da547dd3bb1ebf90e / Yicong Huang <[email protected]> ci: automate backport labeling and open PRs for failed backports (#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 #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 #19](https://github.com/Yicong-Huang/texera/pull/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`](https://github.com/Yicong-Huang/texera/commit/ef1df63cc6429b3ea9429a5375007422861934e8) · [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 #22](https://github.com/Yicong-Huang/texera/pull/22) | | fix touching only files absent on the release branch → not labeled | ✅ | [PR #20](https://github.com/Yicong-Huang/texera/pull/20) | | `no-backport-needed` → all backport work vetoed | ✅ | [PR #21](https://github.com/Yicong-Huang/texera/pull/21) | | remove a label then edit → not re-added (opt-out remembered) | ✅ | [PR #23](https://github.com/Yicong-Huang/texera/pull/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) <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/30310572905 With regards, GitHub Actions via GitBox
