You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@texera.apache.org by GitBox <gi...@apache.org> on 2026/07/29 20:03:44 UTC
[GH] (texera/gh-readonly-queue/main/pr-7042-965786f2a51dc3043b6342fd539f0fddc7f00e53): Workflow run "Required Checks" is working again!
The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-7042-965786f2a51dc3043b6342fd539f0fddc7f00e53 has succeeded.
Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).
Head commit for run:
9d4f69a30f8415c8e53b65a2d619779ab80b3ad5 / Yicong Huang <17...@users.noreply.github.com>
ci: speed up merge queue via HEADGREEN and stack selection (#7042)
### What changes were proposed in this PR?
Two complementary merge-queue speedups.
**1. Retune the `merge_queue` ruleset in `.asf.yaml`:**
| Parameter | Before | After | Why |
| --- | --- | --- | --- |
| `grouping_strategy` | ALLGREEN | HEADGREEN | Merge a whole batch on
one green head-group run instead of one green run per queued PR; also
cuts flaky-test exposure from N draws per batch to 1. |
| `max_entries_to_build` | 5 | 2 | Under HEADGREEN, non-head speculative
builds no longer gate merging; keep one in flight for pipelining, save
shared ASF runner quota (the pool has been at its 900-job limit lately;
policy caps a project at 20 concurrent jobs, and one full group is
already ~20). |
| `min_entries_to_merge` | 1 | 2 | Batch PRs so one full CI run merges
several at peak times. |
| `min_entries_to_merge_wait_minutes` | 5 | 3 | Short batching window;
off-peak a lone PR waits at most 3 minutes. |
| `check_response_timeout_minutes` | 30 | 45 | Headroom for runner-queue
delays so a late-reporting check is not misjudged as failed. |
**2. Smarter stack selection for `merge_group` runs (precheck.yml).**
Previously merge groups ran every stack unconditionally. Now, per group:
```
merge_group
├─ resolve the group's PRs from squash messages "(#N)" (same convention as direct-backport-push.yml)
├─ tier 1: group tree == a PR head tree that already passed Required Checks
│ → byte-identical content was just validated → skip every stack
├─ tier 2: otherwise, union the labels of every PR in the group and apply
│ the same LABEL_STACKS filter a PR event gets
└─ any resolution failure → fail open, run every stack
```
Tier 1 typically fires for a single fresh PR based on the current `main`
tip (or a stacked PR containing the group's other entries) — tree
equality makes the skip content-exact, not heuristic. Backport targets
stay PR-event-only; merge-group backports are still discovered
post-merge by `direct-backport-push.yml`, which already iterates every
commit in a multi-PR push.
### Any related issues, documentation, discussions?
Closes #7041. Ruleset parameters follow the GitHub rulesets
`merge_queue` schema: https://docs.github.com/en/rest/repos/rules
### How was this PR tested?
- Config-only + workflow-logic change; `.asf.yaml` and both workflows
pass YAML parsing, and the embedded github-script block passes `node
--check`.
- The merge-group path fails open on any API/parse error (single
try/catch → full run), so a bad lookup can never skip CI silently.
- Real merge_group behavior can only be observed on `main`; will watch
the first few queue batches after merge (skip/label-union decisions are
logged in the precheck step).
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Fable 5)
---------
Co-authored-by: Claude Fable 5 <no...@anthropic.com>
Report URL: https://github.com/apache/texera/actions/runs/30485770115
With regards,
GitHub Actions via GitBox