mengw15 opened a new pull request, #8096: URL: https://github.com/apache/texera/pull/8096
### What changes were proposed in this PR? A `fix:` PR into `main` is auto-labeled with every actively-supported `release/*` branch, and until now that label alone decided the backport: whatever was labeled at merge time got cherry-picked to the release branch, whether or not the branch's release manager had looked at it. The review request #6940 added is advisory only. This makes the label a nomination and the manager's approval the decision. In Direct Backport Push's discover step, each labeled target is now checked against the latest review state of the `manager` configured for that branch in `.github/release-branches.yml`, before any of the much more expensive apply/build signal reads. Managers gate their own branch and nothing else, so approvals compose — with `release/v1.2` and `release/v1.3` both labeled, an approval from the v1.2 manager alone lands the fix on v1.2 and leaves v1.3 behind; both approving lands it on both; neither approving lands it on neither. `COMMENTED` reviews never change an approval and a later `CHANGES_REQUESTED` or `DISMISSED` revokes one; a manager who authored the fix counts as approving it, since GitHub does not let anyone approve their own PR; a target configuring no `manager` stays ungated; and an unreadable review list holds every gated target back rather than guessing. A held-back target otherwise leaves no trace — no cherry-pick, no draft backport PR, no check — so the merged PR gets a comment naming each one and why it was held back: no approval yet, an approval dismissed before the merge, changes requested, or a review list that could not be read at all. The distinction matters because a flat "not approved" reads as "you never looked at it" even when the manager had approved; it is also why an unreadable review list is kept distinct from an empty one instead of collapsing both to "nobody approved". The pre-merge auto-label report states the requirement up front, so it is visible before the merge rather than only after it. ### Any related issues, documentation, discussions? Closes #8084. Follow-on to #6940, which built this backport pipeline. ### How was this PR tested? Drove the gate (`managerReviewStates` + `splitByApproval`) and the comment's reason renderer through a Node harness covering 17 cases: the three headline outcomes (both managers approve / one approves / neither), revocation by a later `CHANGES_REQUESTED` and by a `DISMISSED`, an approval surviving a later `COMMENTED`, re-approval after changes were requested, a non-manager's approval not counting, manager-as-author, an ungated target, case-insensitive login matching, a failing `listReviews` holding every gated target back, and the wording each of the four hold-back reasons produces. All pass. Deliberately inverting the approval check, dropping the dismissed-approval wording, and collapsing the unreadable-review-list case each turn the run red (exit 1), so the harness can genuinely fail. Both edited workflows parse as YAML, every embedded `github-script` body passes `node --check`, and `release_branches.py` still parses the annotated config unchanged. The harness is not checked in: it recovers the logic by slicing the inline script out of the YAML, so an unrelated comment edit would break it, and the repo has no precedent for unit-testing inline `github-script` bodies. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-5) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
