tools: add more automation for labeling

[avivkeller]

Recently, we changed our stale bot to collect issues and PRs at a much more aggressive rate, and we should see the fruits of that in a few weeks (I think 2?).

However, part of preventing stale and stalled PRs is merging them in a timely fashion, so this PR adds the following automations:

The author ready label is added to a PR when:

• there is a CI run in progress or completed,
• there is at least one collaborator approval,
• there are no outstanding review comments.

The commit-queue label is added to a PR when:

• (All of the above + author ready label)
• open, not a draft, targets main, and mergeable is not CONFLICTING
• at least one approval given against the commit that would land
• semver-major needs two of those approvals to be from TSC voting members
• two approvals and 48 hours since it was opened (unless fast-track)
• every GitHub check passing
• a green Jenkins run when the pull request is labelled needs-ci
• that CI having run in the last five days, so main has not moved on
• a PR is not labeled with a failure label (e.g. commit-queue-failed) or a blocked label blocked, wip, etc

cc @nodejs/TSC

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[panva]

I don't think either one of those is a good idea.

author ready PRs that have at least one approval, no pending requests for changes, and a CI started.

• there is a CI run in progress or completed,
• there is at least one collaborator approval,

Many a time this is not an indication of an author ready PR. Possibly for outside contributions, but for collaborators who "author" and drive their own PRs to completion this isn't case. A review may fly in while i'm running full CI to figure out a failure. Not a ready PR.

---

commit-queue Add this label to land a pull request using GitHub Actions.

That's just asking for trouble

[avivkeller]

The author ready description is:

PRs that have at least one approval, no pending requests for changes, and a CI started.

So I based the criteria off of that, perhaps I can change it to only run when there's a passing CI and none in progress?

That's just asking for trouble

Hypothetically it hopefully shouldn't, it'll only run on PRs that are ready to land, no?

[Renegade334]

+1 to panva's sentiments. I do get the motivation, but I think that a workflow that gives potentially-mergeable PRs a "nudge" after a couple of weeks (just a comment or something similar) would be far more appropriate. One definition for this could be a PR with one or more collaborator approvals, and no failures from GHA's own check suites (ie. excluding Jenkins failures).