Repository navigation
[OMNIML-6182] [1/2] Run the required checks in GitHub's merge queue - #2858
Draft
shengliangxu wants to merge 3 commits into
Draft
shengliangxu wants to merge 3 commits into
shengliangxu wants to merge 3 commits into
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
shengliangxu
added this pull request to stack #2856
October 17, 2026 06:44
Contributor
This was referenced Oct 17, 2026
[OMNIML-6179] [5/11] Make the ONNX tests cheaper: CPU-only ones to the unit lane, small models
#2849
Open
Collaborator
Author
|
/ok to test c45aa28 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2858 +/- ##
==========================================
- Coverage 76.99% 76.44% -0.56%
==========================================
Files 658 658
Lines 73950 73950
==========================================
- Hits 56939 56530 -409
- Misses 17011 17420 +409
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
shengliangxu
removed this pull request from stack #2856
October 17, 2026 06:58
shengliangxu
changed the base branch from
shengliangx/ci-11-megatron-session-pool
to
main
October 17, 2026 06:58
shengliangxu
force-pushed
the
shengliangx/ci-12-merge-queue
branch
from
October 17, 2026 06:59
c45aa28 to
02dd64c
Compare
Collaborator
Author
|
/ok to test 02dd64c |
Contributor
|
shengliangxu
added this pull request to stack #2861
October 17, 2026 07:34
Collaborator
Author
|
/ok to test 4665a0d |
Collaborator
Author
|
/ok to test ed7fe85 |
shengliangxu
marked this pull request as ready for review
October 18, 2026 22:23
The merge queue builds a temporary branch of the target branch plus the queued pull requests and waits for the required status checks on it. The unit, code quality and docs workflows only ran on pull_request events, and the GPU, example and regression workflows only on pushes to the copy-pr-bot branches (pull-request/N) and on schedule, so no required check would ever report on a merge group. Add the merge_group trigger (checks_requested) to all six workflows and treat a merge group like a PR run: - The gate of the GPU, example and regression workflows and the unit tests' changed-files check diff the group against the commit it was built on (the pr-merge-base action reads it from the merge_group payload), so the same lanes run as on the PR and the wait for the unit `linux` check stays. - The *-pr-required-check aggregators, the single-GPU runners, the example timeouts, hf_ptq's -n 4 and the left-out `manual` unit tests all key off "a PR run", which now includes a merge group. - TruffleHog scans base..head of the group, like a PR. - The Codecov uploads are skipped: a queue commit never lands on main. Nightly, on-demand and PR runs behave as before. The queue itself is a ruleset setting (see the PR description); CONTRIBUTING.md describes it. Signed-off-by: Shengliang Xu <shengliangx@nvidia.com>
The merge_group triggers had no branch filter, so a merge queue enabled on any branch would start the required checks there. Give the six triggers the branches of their pull_request triggers (main, release/*, feature/*), which are the branches that have the required checks, and say so in CONTRIBUTING.md. Signed-off-by: Shengliang Xu <shengliangx@nvidia.com>
The PR-like predicate made several runner, if and env values up to 193 columns wide. Fold them into `>-` scalars broken after `&&` / `||` (the parsed YAML value is byte-identical) and wrap two shell conditions and two comments, so no line this PR adds is longer than 110 columns. Signed-off-by: Shengliang Xu <shengliangx@nvidia.com>
shengliangxu
force-pushed
the
shengliangx/ci-12-merge-queue
branch
from
October 18, 2026 22:23
ed7fe85 to
e260b71
Compare
shengliangxu
marked this pull request as draft
October 19, 2026 19:59
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Type of change: CI (merge queue support)
GitHub's merge queue builds a temporary branch of
mainplus the queued PR (gh-readonly-queue/main/pr-<N>-<sha>) and waits for the required status checks to report on it. Today none would: the unit tests, code quality and docs run onpull_requestevents, and the GPU, example and regression workflows only on pushes to the copy-pr-bot branches (pull-request/N) and on schedule. This adds themerge_grouptrigger to all six, limited tomain,release/*andfeature/*(the branches of theirpull_requesttriggers), and makes a merge group count as a PR run:_pr_gate.yml, the example gate) and the unit tests' changed-files check diff the group against the commit it was built on, so the same lanes run as on the PR and the wait for the unitlinuxcheck stays. Thepr-merge-baseaction readsbase_shaandhead_shafrom themerge_grouppayload for this; the unit workflow passes them tochanged-filesdirectly (empty on a PR, where the action finds its base itself).*-pr-required-checkaggregators (the required checks), the single-GPU runners, the example timeouts, hf_ptq's-n 4, and leaving out themanualtests (unit lane).base_sha..head_shalike a PR. The Codecov uploads are skipped for a group: its commit never lands onmain, and the unit job's upload (fail_ci_if_error: true) could otherwise fail a required check.How the queue treats PRs: each PR still lands as its own commit (the
mainruleset allows squash only). The temporary branch of a group is only for testing: the target branch plus the PRs ahead of it plus this one. If its checks fail, that PR is removed from the queue, the PRs ahead of it carry on, and the PRs behind it are re-tested without it.PR runs, nightly runs and on-demand runs behave exactly as before (see Testing). What this PR does not do is turn the queue on: that is a ruleset setting, see below.
Enabling the queue (repository admin, once this PR is in)
A queue is a ruleset rule, so it takes one change per branch family, for the three the checks run for:
main. Add Require merge queue with merge method Squash (the only method this ruleset allows). Starting values, to tune to the GPU runner capacity: build concurrency 2, merge 1 to 4 entries, wait 5 min for more entries, Only merge non-failing pull requests on, and a status check timeout of at least 90 minutes: the GPU workflow takes 59 min at the median today (its jobs time out at 60 min), so the default of 60 would eject slow groups. The required checks stay as they are (DCO,code-quality,build-docsand the four*-pr-required-check).release/*. The same rule. Its ruleset allows merge, squash and rebase, so the queue's method is a choice (squash keeps the history likemain). Its required checks (DCO,code-quality,build-docs, and the unit, gpu and example*-pr-required-check) are all reported in a merge group.feature/*. This ruleset has no required status checks today, so a queue there would merge without testing anything. Require the same checks asrelease/*first.release/*orfeature/*branch reports the checks only once it carries thesemerge_grouptriggers: cherry-pick this PR into each active release branch (thecherry-pick-<X.Y.Z>label does that) and mergemaininto each feature branch that will use the queue.aboubezari/fix_autocast_cast_output_producer_bug#303), but each installation has to approve its new "Merge queues: read" permission. If the first queued PR waits onDCOfor good, approve it, or fall back to a job namedDCOonmerge_groupand point the required check at "any source".merge_groupevents for a repository with the queue on, so nothing in this PR's own CI can exercise them.Possible follow-up: a run of a group that gets rebuilt or dequeued is not cancelled (a group's sha is unique, so the concurrency groups never match); the GPU lanes would run to completion.
Time impact (measured in CI)
No change to a PR's own CI run. What the queue adds is a re-run of the required checks at merge time, so a merge takes about as long as the slowest required workflow. Wall time of a PR run today (median of PR runs, 2026-09-25 to 10-09; the unit figure after #2823):
linuxcheck)linux, then the multi-version and Windows legs)So a merge through the queue takes about an hour today, and the GPU and example workflows set it. The separate speed-up series (#2845-#2855) brings the GPU workflow to 36-40 min and the example workflow to 19-29 min in its own PR runs. The queue's status check timeout has to cover the slower figure, see below.
Usage
Nothing changes for contributors until the queue is on; then merging a PR adds it to the queue (CONTRIBUTING.md).
Testing
branchesfilter undermerge_groupis the documented one (GitHub's events reference: it runs the workflow "only for merge groups that target specific branches"), with the same patterns as thepull_requesttriggers.if,runs-on,envandwithexpressions under a push topull-request/N,schedule,workflow_dispatch,pull_requestand a push tomain, and finds the same value as on the base for each; for amerge_groupevent every one gives what a PR run gives. The shell condition for hf_ptq's-n 4was run for the same cases.merge_groupevent, for the reason above. Themerge_grouppayload fields (base_sha,head_sha) and thechecks_requestedtype are the documented ones, and the TruffleHog action's handling ofbaseandheadinputs was read in its source.Before your PR is "Ready for review"
Make sure you read and follow Contributor guidelines and your commits are signed (
git commit -s -S).Make sure you read and follow the Security Best Practices (e.g. avoiding hardcoded
trust_remote_code=True,torch.load(..., weights_only=False),pickle, etc.).CONTRIBUTING.md: no new dependencyAdditional Information
Slice 1 of 2 of the merge queue work; #2860 is stacked on it. Independent of the GPU-CI speed-up series (#2845-#2855, reference draft #2730): it is based on
mainand changes nothing until a repository admin enables the queue. Both touchunit_tests.yml,gpu_tests.ymlandregression_tests.ymlin neighbouring lines, so whichever lands second needs a trivial rebase. The series adds two conditions that key off a PR run,--run-releasein #2847 and the swinv2 skip of the torch_onnx test in #2853; if this PR lands first they need the samemerge_groupcase (a one-line change each), and if the series lands first this PR carries it.Summary by CodeRabbit