tools: keep not-ready PRs in commit queue

[panva]

Makes the commit-queue label mean "land this PR once it becomes eligible", instead of requiring the PR to already pass the workflow's pre-filter.

The workflow keeps the previous age-based and fast-track query buckets, then also fetches the broader commit-queue set and de-duplicates the result. That keeps the old ready-ish candidates ahead of early queue requests if GitHub paginates or caps a broad query result.

The CQ action now runs git node land before removing the commit-queue label. If git node land reports a retryable readiness condition, such as missing approvals, wait time, missing/pending CI, or stale review/CI state, the label stays in place and a later scheduled run can retry. If a hard failure is present, such as conflicts, closed/merged PR state, failed CI, patch application failure, or other hard failures, the label is removed and commit-queue-failed is reported as before.

Fast-track PRs use the same path. If the fast-track request does not yet have enough collaborator 👍 reactions, the PR stays queued until either the fast-track request is approved or the regular wait-time rules allow landing. Missing fast-track request comments are reported instead of being retried indefinitely.

The docs were also updated to clarify that the five-minute cron is a best-effort GitHub Actions schedule, not a guaranteed execution cadence, and that CQ does not request CI by itself.

Caveat: the retry/hard-failure split still depends on matching git node land output. A machine-readable readiness result from @node-core/utils would be more robust and worthy of a follow up.

Alternative to #64340, #64262, and #62498, which unlike the others keeps commit-queue as an always-addable landing request and lets git node land apply the existing landing rules instead of trying to precompute eligibility in the workflow or a separate label-management action.

[nodejs-github-bot]

Review requested:

• @nodejs/actions
• @nodejs/tsc

[aduh95]

I'm -1 on that:

• This solution is very inefficient, the only reason it's split in two workflows is so we can have a tiny one that checks if there's any eligible PR, so we can skip the much heavier one that has to clone the full repo, download NCU, run all the checks etc. IIUC the first job would always have results, given that folks would be incentivized to add the label very early even before getting reviews
• checking for NCU output is too fragile IMO
• if a PR is not landable, it will make it much harder to understand why as it won't send notification like it does today, and the actual output will be burried in a see of other PRs in the queue despite not being ready

[panva]

I think we need to pick which tradeoff we want here.

If we do not want to duplicate landability rules outside @node-core/utils, then the CQ has to ask NCU whether the PR can land and react to that result. That is what this patch does (and acknowledges exactly what the followup would be to make it less brittle).

if a PR is not landable, it will make it much harder to understand why as it won't send notification like it does today, and the actual output will be burried in a see of other PRs in the queue despite not being ready

👇

The CQ action now runs git node land before removing the commit-queue label. If git node land reports a retryable readiness condition, such as missing approvals, wait time, missing/pending CI, or stale review/CI state, the label stays in place and a later scheduled run can retry. If a hard failure is present, such as conflicts, closed/merged PR state, failed CI, patch application failure, or other hard failures, the label is removed and commit-queue-failed is reported as before.

[aduh95]

The CQ can be used by e.g. triaggers, so IMO it makes sense for it to have stricter rules than NCU (and NCU is not the source of truth either, our governance document is, which NCU tries to implement but has edge cases)