Review requested:

• @nodejs/loaders

Fast-track has been requested by @JakobJingleheimer. Please 👍 to approve.

Codecov Report

Attention: Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.

Project coverage is 88.41%. Comparing base (3a0968d) to head (c46b198).
Report is 93 commits behind head on main.

@@            Coverage Diff             @@
##             main   #55820      +/-   ##
==========================================
- Coverage   88.41%   88.41%   -0.01%     
==========================================
  Files         654      654              
  Lines      187811   187810       -1     
  Branches    36134    36129       -5     
==========================================
- Hits       166052   166043       -9     
- Misses      15008    15011       +3     
- Partials     6751     6756       +5     

... and 28 files with indirect coverage changes

CI: https://ci.nodejs.org/job/node-test-pull-request/63522/

CI: https://ci.nodejs.org/job/node-test-pull-request/63527/

CI stalled a few hours ago. Everything has passed except the top task. Should I kill it and resume?

CI stalled a few hours ago. Everything has passed except the top task. Should I kill it and resume?

I'd recommend not. Apparently we only have one macos11-x64 machine available, so there's a large backlog of jobs waiting for it to become available. Cancelling and requeuing will put your job at the back of the queue.

cc @nodejs/build

Apparently we only have one macos11-x64 machine available, so there's a large backlog of jobs waiting for it to become available

I think that was not the problem because all jobs had finished (including the macos ones) except the root container job. IIR, this happened to my previous PR when a release was in progress, so I think there is a problem with the CI config.

Landed in b52a49b

because all jobs had finished (including the macos ones) except the root container job

That's not correct, you were likely confused by the Jenkins UI. FWIW I can confirm what Richard said, the osx11 job was still pending 13 hours ago and only started later when the backlog of jobs from other PRs was eaten up. You can see that the child job says it "took 2 hr 27 min", while the parent job says it "took 17 hr".

this happened to my previous PR when a release was in progress

It may be that during a release preparation a backlog is more likely build up – going from one branch to another means machine cannot reuse as much binary cache and therefore spend more time building. But I don't see what CI config could we change, to me it feels more a problem that would be solved by having more OSX machines at our disposal.

Ah, okay! Very okay to concede I was confused bt the Jenkins UI 😅

Thanks for the investigation and explanation! I don't know how much work it would be or if it's even possible, but some kind of banner "Release in progress, hang tight" would be great!

This commit does not land cleanly on v22.x-staging and will need manual backport in case we want it in v22.x.