tools: keep not-ready PRs in commit queue#64343
Conversation
Make the commit queue treat `commit-queue` as a request to land a PR once it becomes eligible. The workflow still fetches the previous age-based and fast-track buckets first, then fetches the broader queued set and de-duplicates the result. This keeps early queue requests from crowding out PRs that the previous query would have selected if GitHub paginates or caps a broad query result. Run `git node land` before removing `commit-queue`. If it reports only retryable readiness conditions, keep the label so a later scheduled run can retry. If it reports a hard failure, remove the label and report `commit-queue-failed`. Signed-off-by: Filip Skokan <panva.ip@gmail.com>
|
Review requested:
|
|
I'm -1 on that:
|
|
I think we need to pick which tradeoff we want here. If we do not want to duplicate landability rules outside
👇
|
|
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) |
Makes the
commit-queuelabel 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-queueset 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 landbefore removing thecommit-queuelabel. Ifgit node landreports 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 andcommit-queue-failedis 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 landoutput. A machine-readable readiness result from@node-core/utilswould be more robust and worthy of a follow up.Alternative to #64340, #64262, and #62498, which unlike the others keeps
commit-queueas an always-addable landing request and letsgit node landapply the existing landing rules instead of trying to precompute eligibility in the workflow or a separate label-management action.