@@ -20,32 +20,34 @@ From a high-level, the Commit Queue works as follows:
2020
21211 . Collaborators will add ` commit-queue ` label to pull requests they want the
2222 queue to land. The label can be added before the pull request has completed
23- its wait time, or before requested CI has finished. Required approvals must
24- already be in place. The commit queue does not request CI on its own.
23+ its wait time. Required approvals must already be in place, and any required
24+ CI must have completed successfully. The commit queue does not request CI on
25+ its own.
25262 . On each scheduled run, the queue builds a candidate list from open pull
26- requests with the ` commit-queue ` label and without the ` blocked ` label. The
27- workflow uses a five-minute cron, but GitHub Actions scheduled workflows are
28- not guaranteed to run exactly every five minutes. For each candidate, the
29- queue will:
27+ requests with the ` commit-queue ` label and without the ` blocked ` label. A
28+ candidate must also either have been created at least two days earlier or
29+ have the ` fast-track ` label. Other labeled pull requests retain the label
30+ until they become old enough or are fast-tracked. The workflow uses a
31+ five-minute cron, but GitHub Actions scheduled workflows are not guaranteed
32+ to run exactly every five minutes. For each candidate, the queue will:
3033 1 . In the landing job, install and configure ` @node-core/utils ` , then run a
3134 metadata-only readiness check without checking out the repository
3235 2 . If the metadata check exits with a deferrable readiness code, meaning
3336 the PR is only blocked on wait time, keep the ` commit-queue ` label and
3437 skip this PR until a later queue run
35- 3 . Check if the PR also has a ` request-ci ` label (if it has, skip this PR
36- since it's pending a CI run)
37- 4 . Check whether GitHub checks are still running (if they are, skip this PR)
38- 5 . Remove the ` commit-queue ` label and run ` git node land `
39- 6 . If it fails:
40- 1 . Add the ` commit-queue-failed ` label to the PR
38+ 3 . Run ` git node land ` for ready PRs and PRs with hard or mixed readiness
39+ failures, keeping the ` commit-queue ` label in place during the attempt
40+ 4 . If it fails:
41+ 1 . Replace the ` commit-queue ` label with the ` commit-queue-failed ` label
4142 2 . Leave a comment on the PR with the output from ` git node land `
4243 3 . Abort the ` git node land ` session. If the abort succeeds, continue to
4344 the next PR; otherwise, stop the queue in an unknown state
44- 7 . If it succeeds:
45+ 5 . If it succeeds:
4546 1 . Push or merge the changes into nodejs/node
4647 2 . Leave a comment on the PR with ` Landed in ... `
4748 3 . Close the PR
48- 4 . Go to next PR in the queue
49+ 4 . Remove the ` commit-queue ` label
50+ 5 . Go to next PR in the queue
4951
5052To make the Commit Queue squash all the commits of a pull request into the
5153first one, add the ` commit-queue-squash ` label.
@@ -94,11 +96,11 @@ reasons:
9496 without rebasing them first.
9597
9698The workflow starts with a small candidate job that uses GitHub CLI to fetch
97- pull requests with the ` commit-queue ` label. It first fetches the same
98- age-based and fast-track buckets the queue used before accepting early queue
99- requests, then fetches the broader queue and de-duplicates the result. This
100- keeps not-yet-ready PRs from crowding out PRs that the previous query would
101- have selected if GitHub paginates or caps a query result .
99+ open pull requests with the ` commit-queue ` label and without the ` blocked `
100+ label. It fetches two buckets: pull requests created at least two days earlier
101+ and pull requests with the ` fast-track ` label. The job de-duplicates the
102+ buckets before passing the candidates to the landing job. Pull requests in
103+ neither bucket remain labeled but are not processed during that run .
102104
103105If there are candidate PRs, the landing job installs and configures
104106` @node-core/utils ` once with a personal token and a Jenkins token from
@@ -123,9 +125,10 @@ states. Unknown filter failures fail the workflow before starting the landing
123125script and leave PR labels unchanged so the queue can retry on a later
124126scheduled run. PRs passed through with exit code ` 40 ` -` 49 ` continue through
125127` commit-queue.sh ` . The workflow checks out the repository only when at least
126- one PR remains after filtering. The script still applies its existing
127- ` request-ci ` and pending-check deferrals before removing the queue label and
128- reporting a hard failure.
128+ one PR remains after filtering. The script does not separately skip PRs with a
129+ ` request-ci ` label or pending GitHub checks. Instead, ` git node land ` performs
130+ the landing checks and the script reports any failure through the normal queue
131+ failure path.
129132
130133> The personal token needs permission for public repositories and to read
131134> profiles. It is used by ` @node-core/utils ` and by the landing job for
@@ -139,18 +142,20 @@ reporting a hard failure.
1391423 . Every positional argument starting at this one will be a pull request ID of
140143 a pull request with commit-queue set.
141144
142- The script will iterate over the pull requests. GitHub CLI is used to check if
143- the PR is waiting for CI to start (` request-ci ` label) or still has pending
144- GitHub checks. The PR is skipped if CI is pending. No other CI validation is
145- done here since ` git node land ` will fail if the last CI failed.
146-
147- The script removes the ` commit-queue ` label, then runs ` git node land ` ,
148- forwarding stdout and stderr to a file. PRs that are only blocked on wait time
149- should have already been filtered by the metadata check. If a hard readiness
150- failure appears between the metadata filter and ` git node land ` , the landing
151- job adds a ` commit-queue-failed ` label to the PR, leaves a comment with the
152- output of ` git node land ` , and then aborts the landing session. If the abort
153- fails, the queue stops instead of continuing in an unknown state.
145+ The script iterates over the pull requests. For each PR, it uses GitHub CLI to
146+ fetch the labels and select the multiple-commit policy, then runs
147+ ` git node land ` , forwarding stdout and stderr to a file. It does not perform a
148+ separate CI preflight; ` git node land ` performs the current readiness and CI
149+ validation.
150+
151+ The script keeps the ` commit-queue ` label in place while ` git node land ` is
152+ running. PRs that are only blocked on wait time should have already been
153+ filtered by the metadata check. A hard or mixed readiness failure is passed
154+ through so ` git node land ` can produce the failure output. If the landing
155+ attempt fails for that or any other reason, the job replaces the
156+ ` commit-queue ` label with ` commit-queue-failed ` , leaves a comment with the
157+ output, and then aborts the landing session. If the abort fails, the queue
158+ stops instead of continuing in an unknown state.
154159
155160Fast-tracked PRs use the metadata check before checkout and the landing script.
156161If the fast-track request has not yet received enough collaborator thumbs-up,
@@ -164,8 +169,8 @@ If no errors happen during `git node land`, the script either pushes the direct
164169rebase landing to ` main ` or uses GitHub's squash merge API for single-commit and
165170fixup landings. It then leaves a ` Landed in ... ` comment in the PR. GitHub
166171closes PRs merged through the merge API automatically; for direct pushes, the
167- script closes the PR. Iteration continues until all PRs have done the steps
168- above.
172+ script closes the PR. The script then removes the ` commit-queue ` label.
173+ Iteration continues until all PRs have done the steps above.
169174
170175## Reverting broken commits
171176
0 commit comments