The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-8379-75c85aa7e771d9b3d3c79396b08b196928238858 has failed. Run started by GitHub user mengw15 (triggered by mengw15).
Head commit for run: d213710f9021567c63f11bd4d68e4726d9a03f28 / Meng Wang <[email protected]> ci: give GitHub Actions bypass on the release-branch ruleset (#8379) ### What changes were proposed in this PR? The Merge Queue ruleset requires every change into `release/*` to arrive as a PR with one approving review, green required checks, and a pass through the merge queue. Right for people — but it also blocks `direct-backport-push.yml`, whose fast path pushes clean cherry-picks; every such push has been rejected since 2026-07-24, and five backports were silently lost (#8377). This splits the ruleset in two, rule-for-rule identical: `Merge Queue` keeps `~DEFAULT_BRANCH`, and a new `Merge Queue (release)` carries the three release branches plus a `bypass_actors` entry for the GitHub Actions app (`actor_id: 15368`). The split exists because a bypass is ruleset-wide — kept in one ruleset, it would let workflows push `main` too. Scope, stated precisely: the bypass exempts actions performed as the Actions app — any workflow's `GITHUB_TOKEN`, not just the backport workflow, since rulesets cannot scope a bypass to one workflow. People and PATs still face every rule on every branch; `main` gets no bypass; force pushes and branch deletion stay blocked for everyone, Actions included, by `Default Branch Protection`. Ordering inside the file is load-bearing: asfyaml applies rulesets in file order, so `Merge Queue (release)` is created before `Merge Queue` stops covering the release branches. If GitHub rejects the new ruleset, the apply aborts with today's protections fully intact — no failure path leaves the release branches uncovered. The bypass alone would not revive the fast path: since #4676 the push job checked out with `AUTO_MERGE_TOKEN`, so GitHub evaluated its pushes as that PAT's owner — every pre-ruleset direct push shows a person as the pusher — and an Actions-app bypass would not cover them. The push job now uses the default `GITHUB_TOKEN`, which the bypass does cover, and dispatches `Required Checks` on the pushed branch explicitly, since a `GITHUB_TOKEN` push starts no push-triggered runs while `workflow_dispatch` is the documented exception that always creates one. The conflict path keeps the PAT: it pushes unprotected `backport/*` branches, where the opened PR's CI must still trigger. ### Any related issues, documentation, discussions? Closes #8377. #8378 took the PR-plus-auto-merge route to the same problem and is closed in favor of trying the bypass first. What lands on a release branch through this path is still only a cherry-pick of a commit that passed main's full CI and, once #8096 lands, its release manager's approving review. ### How was this PR tested? `.asf.yaml` and the workflows parse, and the structural check is now committed instead of run once: `.github/scripts/test_asf_rulesets.sh` (picked up by build.yml's glob-discovered infra tests) asserts the two rulesets' `rules` blocks stay deep-equal and that `.asf.yaml` and every workflow parse under a duplicate-key-strict loader, with PyYAML pinned in `amber/dev-requirements.txt` — the file the infra job installs; every failure path (duplicate key, rules drift, bypass on main, bypass tampered, ruleset reorder, missing PyYAML) was verified red before trusting the green. asfyaml treats a ruleset carrying `target`/`rules`/`bypass_actors` as a raw payload and forwards it verbatim (`_RAW_RULESET_KEYS` in `feature/github/rulesets.py`; its upstream tests assert the POST payload carries `bypass_actors`). What cannot be proven before merge is GitHub accepting the Actions app as a bypass actor on this org: the same payload on a personal repository is rejected with "Actor GitHub Actions integration must be part of the ruleset source or owner organization", and no ASF repository uses an Integration bypass actor yet — hence the fail-safe ordering above. After Infra applies the merged file, `GET /repos/apache/texera/rulesets` should list `Merge Queue (release)`; if it does not, the apply failed closed and nothing changed. The next clean backport is the end-to-end test. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-fable-5) Report URL: https://github.com/apache/texera/actions/runs/34606728078 With regards, GitHub Actions via GitBox
