mengw15 opened a new pull request, #8626: URL: https://github.com/apache/texera/pull/8626
### What changes were proposed in this PR? `Direct Backport Push` cherry-picks a cleanly-applying fix onto the release branch and pushes it. Every one of those pushes has been rejected since 2026-07-24: `release/*` is covered by the Merge Queue ruleset, which requires a pull request of everyone. #8379 tried to exempt the Actions app from it; GitHub refuses to create that bypass, and #8624 reverts it. ASF policy points the same way — an automated service must not push to a branch subject to official release without prior authorization from Infrastructure. Both outcomes now open a pull request. The conflicted one is unchanged: a draft, assigned to its author. A clean one opens **ready for review and assigned to nobody**, because there is no code for anyone to write on it. What a clean backport still needs is its checks started, and that is the part worth stating plainly. GitHub creates no workflow run for anything `GITHUB_TOKEN` does, so a bot-opened pull request has none — and nothing will arrive on its own: | action on a pull request with no checks | starts the three required contexts | | --- | --- | | push any commit to the branch | yes (`synchronize`) | | close and reopen it | yes (`reopened`) | | mark it ready for review | **no** — none of the three workflows listens for `ready_for_review` | | add or remove a label | only `Required Checks` | | "Re-run all jobs" | no — with no run there is nothing to re-run | A conflicted backport never had this problem: its author pushes a resolution, and that push brings CI with it. A clean one has nobody to push anything. So the comment the conflict path already posts for its instructions now says, for a clean backport, the one action that works — and says that marking it ready for review is not it. That leaves the release manager three ordinary buttons: reopen, approve, and auto-merge if they would rather not come back when the checks finish. The approval is not automated and should not be: the `release/*` label on the original PR records the decision, and this is the look at the tree that actually lands. Nothing here depends on a token's pull-request scope, on an Actions bypass, or on a close/reopen the workflow performs itself. Those are the paths that can only be proven in production, and that fail quietly when they are wrong — which is how #8432, #8494 and #8562 were lost. `push_entries` is now always empty, leaving `push-backports` unreachable. Removing it is left to a separate change, so that this one is a behaviour change and that one is a pure deletion. ### Any related issues, documentation, discussions? Closes #8377. #8378 proposed the same routing with the workflow performing the close/reopen itself and arming auto-merge; this drops both in favour of the release manager's own click, and is closed in favour of this. ### How was this PR tested? The routing was driven locally against a stubbed `github-script` environment. With the pre-merge preflight green, both targets come out as pull-request entries carrying `clean: "true"` and `push_entries` empty; with it neutral, `clean: "false"`; with no completed signal, neither target is acted on, as before. Restoring the old `pushEntries.push` turns that check red, so it is not vacuous. The workflow parses, and all four inline `github-script` bodies pass `node --check`. That a bot-opened pull request starts with no checks is what this repository already shows: #8584 — bot-opened, one commit, nobody pushed to it — carries no check runs at all, while #8553, opened the same way, has the full set after a commit was pushed. That `ready_for_review` does not start them is in the triggers: `required-checks.yml` lists `opened`/`reopened`/`synchronize`/`labeled`/`unlabeled`, `check-header.yml` takes the bare `pull_request:` defaults, and `lint-pr.yml` lists `opened`/`edited`/`reopened`/`synchronize`. Not provable before merge: that a human reopen produces the three contexts on a backport PR. #8619 to #8623 — five backports into `release/v1.3` opened by hand this week — show that the contexts do appear and pass on a pull request into a release branch; the reopen path shares everything with them but the event that starts the run. ### Was this PR authored or co-authored using generative AI tooling? Yes. 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]
