Review requested:

• @nodejs/actions

continue-on-error should be removed because gh pr list does not fail if it does not find any pull requests.
And if: steps.get_prs_for_ci.outputs.numbers (the output will be empty if no pull request has been found) should be used instead of if: success().

to avoid having to do a lot of if: condition, we could refactor the workflow into two different jobs:

• first job runs the Get Pull Requests step
• second job is conditional, depends on the first one and runs the other steps

wdyt?

Edit: bonus would be that the workflow graph would clearly show whether there were PRs to land or not.

to avoid having to do a lot of if: condition, we could refactor the workflow into two different jobs:

• first job runs the Get Pull Requests step
• second job is conditional, depends on the first one and runs the other steps

wdyt?

I love the idea, unfortunately there are no easy way to share the result between the two jobs (the only solution I found was to upload an artifact, not ideal, overkill for this use case). I've made the if if if solution finally works on my fork, I'm going to push that here, but if someone thinks of something more elegant, I'll take it.

there are no easy way to share the result between the two jobs

You can use outputs of a job in another. See https://github.com/zakodium/workflows/blob/main/.github/workflows/release.yml#L26-L54

This could use another review so I can land sooner. @Trott maybe you'd want to do that, since you are the one who reported the issue in #40985 (comment).

Landed in 587b167

Now it looks like request-ci isn't working at all and this job fails even when it finds PRs.... https://github.com/nodejs/node/runs/4569665939?check_suite_focus=true

One drawback of the approach in this PR is there's now a race condition on the Auto-Start CI action (and probably the CQ too): #41388

From what I understand, this would happen when there are too many running jobs on the org that it starts to queue up, the get_prs_for_ci jobs run before one of the startCI jobs has time to remove the label. There are no terrible consequences – and hopefully it should not happen too often – but it's a bit annoying. Ideally we would want to skip these actions if the previous one hasn't ran yet, not sure it's actually doable though.