The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-8626-60a37b1e8495b7d16b1458560ae48d0834f7c513 has succeeded. Run started by GitHub user mengw15 (triggered by mengw15).
Head commit for run: 35be7c72005cbe47e7bcf675920f96ed786467a9 / Meng Wang <[email protected]> ci: open a pull request for a clean backport instead of pushing it (#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) Report URL: https://github.com/apache/texera/actions/runs/35658500353 With regards, GitHub Actions via GitBox
