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: 438bca5a94eecff8c49589b30cb7f17fbdc5da6c / 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. The review request #6940 added is advisory only. Worse than the missing gate is what it does to the record. A manager who does not want a fix on their branch declines by staying silent, so the label stays on. The PR merges carrying `release/v1.2`, nothing is backported there, and months later that label says the fix shipped in 1.2 when it did not. Make the approval required to merge. `Backport Approvals` 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 Direct Backport Push then sends the fix to — the record is true by construction rather than by anyone remembering to tidy up. The rule: - 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 blocked. - 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. The check runs on every pull request, including ones with nothing to approve, because a required context that never appears blocks its PR forever. It re-evaluates merge groups rather than waving them through, since a queued PR's own checks are no longer consulted. Retargeting arrives as `edited`, which is in the trigger list because the verdict depends on the base branch. The 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 — 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/33391284992 With regards, GitHub Actions via GitBox
