tools: only include fast-tracked and old enough PRs in CQ

Signed-off-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: #65197
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>

Author: aduh95

.github/workflows/commit-queue.yml

@@ -48,9 +48,7 @@ jobs:
           fast_track_prs=$(list_prs \
                   --label 'fast-track' \
                   --search "-label:blocked")
-          queued_prs=$(list_prs \
-                  --search "-label:blocked")
-          candidates=$(printf '%s %s %s\n' "$aged_prs" "$fast_track_prs" "$queued_prs" |
+          candidates=$(printf '%s %s\n' "$fast_track_prs" "$aged_prs" |
                   jq -r -s 'reduce .[] as $pr ([]; if index($pr) then . else . + [$pr] end) | join(" ")')
           echo "candidates=$candidates" >> "$GITHUB_OUTPUT"
         env:

doc/contributing/commit-queue.md

@@ -20,32 +20,34 @@ From a high-level, the Commit Queue works as follows:
 
 1. Collaborators will add `commit-queue` label to pull requests they want the
    queue to land. The label can be added before the pull request has completed
-   its wait time, or before requested CI has finished. Required approvals must
-   already be in place. The commit queue does not request CI on its own.
+   its wait time. Required approvals must already be in place, and any required
+   CI must have completed successfully. The commit queue does not request CI on
+   its own.
 2. On each scheduled run, the queue builds a candidate list from open pull
-   requests with the `commit-queue` label and without the `blocked` label. The
-   workflow uses a five-minute cron, but GitHub Actions scheduled workflows are
-   not guaranteed to run exactly every five minutes. For each candidate, the
-   queue will:
+   requests with the `commit-queue` label and without the `blocked` label. A
+   candidate must also either have been created at least two days earlier or
+   have the `fast-track` label. Other labeled pull requests retain the label
+   until they become old enough or are fast-tracked. The workflow uses a
+   five-minute cron, but GitHub Actions scheduled workflows are not guaranteed
+   to run exactly every five minutes. For each candidate, the queue will:
    1. In the landing job, install and configure `@node-core/utils`, then run a
       metadata-only readiness check without checking out the repository
    2. If the metadata check exits with a deferrable readiness code, meaning
       the PR is only blocked on wait time, keep the `commit-queue` label and
       skip this PR until a later queue run
-   3. Check if the PR also has a `request-ci` label (if it has, skip this PR
-      since it's pending a CI run)
-   4. Check whether GitHub checks are still running (if they are, skip this PR)
-   5. Remove the `commit-queue` label and run `git node land`
-   6. If it fails:
-      1. Add the `commit-queue-failed` label to the PR
+   3. Run `git node land` for ready PRs and PRs with hard or mixed readiness
+      failures, keeping the `commit-queue` label in place during the attempt
+   4. If it fails:
+      1. Replace the `commit-queue` label with the `commit-queue-failed` label
       2. Leave a comment on the PR with the output from `git node land`
       3. Abort the `git node land` session. If the abort succeeds, continue to
          the next PR; otherwise, stop the queue in an unknown state
-   7. If it succeeds:
+   5. If it succeeds:
       1. Push or merge the changes into nodejs/node
       2. Leave a comment on the PR with `Landed in ...`
       3. Close the PR
-      4. Go to next PR in the queue
+      4. Remove the `commit-queue` label
+      5. Go to next PR in the queue
 
 To make the Commit Queue squash all the commits of a pull request into the
 first one, add the `commit-queue-squash` label.
@@ -94,11 +96,11 @@ reasons:
    without rebasing them first.
 
 The workflow starts with a small candidate job that uses GitHub CLI to fetch
-pull requests with the `commit-queue` label. It first fetches the same
-age-based and fast-track buckets the queue used before accepting early queue
-requests, then fetches the broader queue and de-duplicates the result. This
-keeps not-yet-ready PRs from crowding out PRs that the previous query would
-have selected if GitHub paginates or caps a query result.
+open pull requests with the `commit-queue` label and without the `blocked`
+label. It fetches two buckets: pull requests created at least two days earlier
+and pull requests with the `fast-track` label. The job de-duplicates the
+buckets before passing the candidates to the landing job. Pull requests in
+neither bucket remain labeled but are not processed during that run.
 
 If there are candidate PRs, the landing job installs and configures
 `@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
 script and leave PR labels unchanged so the queue can retry on a later
 scheduled run. PRs passed through with exit code `40`-`49` continue through
 `commit-queue.sh`. The workflow checks out the repository only when at least
-one PR remains after filtering. The script still applies its existing
-`request-ci` and pending-check deferrals before removing the queue label and
-reporting a hard failure.
+one PR remains after filtering. The script does not separately skip PRs with a
+`request-ci` label or pending GitHub checks. Instead, `git node land` performs
+the landing checks and the script reports any failure through the normal queue
+failure path.
 
 > The personal token needs permission for public repositories and to read
 > profiles. It is used by `@node-core/utils` and by the landing job for
@@ -139,18 +142,20 @@ reporting a hard failure.
 3. Every positional argument starting at this one will be a pull request ID of
    a pull request with commit-queue set.
 
-The script will iterate over the pull requests. GitHub CLI is used to check if
-the PR is waiting for CI to start (`request-ci` label) or still has pending
-GitHub checks. The PR is skipped if CI is pending. No other CI validation is
-done here since `git node land` will fail if the last CI failed.
-
-The script removes the `commit-queue` label, then runs `git node land`,
-forwarding stdout and stderr to a file. PRs that are only blocked on wait time
-should have already been filtered by the metadata check. If a hard readiness
-failure appears between the metadata filter and `git node land`, the landing
-job adds a `commit-queue-failed` label to the PR, leaves a comment with the
-output of `git node land`, and then aborts the landing session. If the abort
-fails, the queue stops instead of continuing in an unknown state.
+The script iterates over the pull requests. For each PR, it uses GitHub CLI to
+fetch the labels and select the multiple-commit policy, then runs
+`git node land`, forwarding stdout and stderr to a file. It does not perform a
+separate CI preflight; `git node land` performs the current readiness and CI
+validation.
+
+The script keeps the `commit-queue` label in place while `git node land` is
+running. PRs that are only blocked on wait time should have already been
+filtered by the metadata check. A hard or mixed readiness failure is passed
+through so `git node land` can produce the failure output. If the landing
+attempt fails for that or any other reason, the job replaces the
+`commit-queue` label with `commit-queue-failed`, leaves a comment with the
+output, and then aborts the landing session. If the abort fails, the queue
+stops instead of continuing in an unknown state.
 
 Fast-tracked PRs use the metadata check before checkout and the landing script.
 If 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
 rebase landing to `main` or uses GitHub's squash merge API for single-commit and
 fixup landings. It then leaves a `Landed in ...` comment in the PR. GitHub
 closes PRs merged through the merge API automatically; for direct pushes, the
-script closes the PR. Iteration continues until all PRs have done the steps
-above.
+script closes the PR. The script then removes the `commit-queue` label.
+Iteration continues until all PRs have done the steps above.
 
 ## Reverting broken commits