The GitHub Actions job "Backport Approval Check" on texera.git/ci/8084-backport-manager-approval-gate has failed. Run started by GitHub user Copilot (triggered by Copilot).
Head commit for run: e03972940ed1739403b400670e28e6fb09d3ca26 / mengw15 <[email protected]> ci: block the merge until each release/* label has its manager's approval A `fix:` PR is auto-labeled with every actively-supported `release/*` branch, and the label alone decided the backport: whatever was labeled at merge time was cherry-picked to the release branch, whether or not that branch's release manager had looked at it. Making the label a nomination and the manager's approval the decision is only half of it, because a manager who declines by staying silent leaves the label behind. The PR then merges carrying `release/v1.2` while nothing was backported there, and read back months later that label says the fix shipped in 1.2 when it did not. So the approval is now required to merge. `Backport Approvals` (.github/workflows/backport-approval-check.yml) is red while any `release/*` label on the PR lacks its manager's approval, and it is listed in .asf.yaml's required_status_checks. Declining becomes an action rather than silence: the manager removes their branch's label, which clears the check for that branch. Since the merge waits for every remaining label to be approved, the labels on a merged PR are exactly the branches it was backported to — the record is true by construction rather than by anyone remembering to tidy up. The rule itself: - Managers gate their own branch and nothing else, so approvals compose — an approval from the v1.2 manager alone clears v1.2 and leaves v1.3 waiting. - COMMENTED reviews never change an approval; a later CHANGES_REQUESTED or DISMISSED revokes one. Any dismissal lands on DISMISSED, so that state proves an approval is not standing, never what the dismissed review had been. - A manager who wrote the fix counts as approving it, since GitHub does not let anyone approve their own PR. - An entry that omits `manager` stays ungated, but a label naming a branch release-branches.yml does not list at all is held back: retiring a branch means dropping its entry while its label lives on, and nobody is then designated to approve it. - An unreadable review list holds every gated target back rather than guessing. That rule lives in .github/scripts/backport-gate.js because two workflows now have to answer it identically. Direct Backport Push asks again immediately before pushing, since the pre-merge check cannot cover a dismissal once a PR is in the merge queue, and it remains the only place that can refuse at the moment the release branch is written. Were the two to drift, a check that passed while the push declined would silently reintroduce the very misleading label this change removes. The check's failure report is the whole explanation an author gets, and that author may be an outside contributor or Renovate, neither of which can edit labels at all — that needs triage access. So it names the manager, gives both ways out, and says who to ask when the reader can do neither. Report URL: https://github.com/apache/texera/actions/runs/33371140957 With regards, GitHub Actions via GitBox
