tools: prefilter commit queue metadata

[panva]

Alternative to #64340, #64262, and #62498 which unlike the others keeps the existing commit queue landing and failure-reporting path intact, while only adding a lightweight metadata prefilter before the heavy checkout job.

This makes the commit-queue label addable before a PR is fully landable. The lightweight selector runs git node metadata --readme without checking out the repository. If a PR is only waiting for approval count, TSC approval count, or wait time, the workflow leaves the label in place and retries on a later scheduled run.

Everything else still goes through the existing commit-queue.sh path: CI state, requested changes, conflicts, stale review/CI state, new contributor checks, closed/merged PRs, and unknown failures. That keeps the current commit-queue-failed label and failure comment behavior where it is today.

The candidate query also fetches the previous age-based and fast-track buckets before the broader queue and deduplicates them in that order, so early-queued PRs do not crowd out PRs that would have been selected by the previous query if GitHub caps or paginates results.

[nodejs-github-bot]

Review requested:

• @nodejs/actions
• @nodejs/tsc

[joyeecheung]

FWIW there's git node metadata which doesn't need to clone the whole repo (it only needs the README for collaborator info, which can be downloaded standalone and you point to it via --readme), it just generates metadata and verifies if the PR is ready. If we don't want rules being scattered everywhere we can just also consolidate them to be a package and share it (in NCU, it's just the PRChecker class). NCU itself was not initially written for CI automation as it predated GHA, we only added --yes later that just tried to silence questions so that it can be used in a commit queue, but the output was never polished to be programmably consumed. If we need that it should either be polished to output structured information or we can just extract a package with a proper API.

[panva]

Reworked based on @joyeecheung's observation. This now uses git node metadata --readme in the lightweight selector job, so PRs that are only waiting for approval count, TSC approval count, or wait time keep the commit-queue label without starting the checkout-heavy landing job.

Everything else is left to the existing commit-queue.sh path, including CI state, requested changes, conflicts, stale review/CI state, new contributor checks, closed/merged PRs, and unknown failures. That keeps the current failure-label/comment behavior in the same place while making the label usable before a PR is fully landable.

[panva]

A proper API for NCU is still a thing to take care of. The selector currently has to classify git node metadata by matching human-readable output, which is inherently brittle. A follow-up should make NCU expose structured readiness results, for example with stable reason codes like missing-approval, wait-time, missing-ci, conflict, or requested-changes.

Then this workflow could defer only the reason codes it intentionally owns, and pass everything else to the existing landing path without depending on exact wording in CLI output.

[panva]

Updated to consume structured @node-core/utils readiness API (nodejs/node-core-utils#1113) instead of matching human-readable git node metadata output.

The selector now runs git node metadata <pr> --readme <README.md> --json and branches on the metadata exit-code contract:

• 0: PR is ready, pass it to commit-queue.sh
• 20-29: deferrable not-ready state, keep commit-queue and retry later
• 40-49: hard or mixed metadata failure, pass it to the existing commit-queue.sh failure path
• anything else: fail the selector before starting the checkout-heavy landing job

This removes the brittle grep-based classifier while keeping the original split of responsibility: the lightweight selector only owns deferrable readiness states, and the existing landing path still owns failure labels/comments for hard failures.