Support for llnode builds

[No9]

Hi Builders
Over in llnode we have some flaky tests due to later versions of LLVM requiring more resources than the default 2 core 7Gb RAM that is allocated to shared GH Actions.
See the node v14 failure here: https://github.com/nodejs/llnode/runs/7931316354

On the last @nodejs/diagnostics call 2022-08-23 we discussed possible options such as GitHub Actions self hosted runners in order to provide more resources to the build.
Is using self hosted runners on GH actions an option for projects in the node org or is there something else we can use to run ~34 Ubuntu 18/20 jobs?
Thanks for any info you can provide and please let us know if you need more details.

[richardlau]

Is using self hosted runners on GH actions an option for projects in the node org or is there something else we can use to run ~34 Ubuntu 18/20 jobs?

Right now, self-hosted GH runners are not an option. @mmarchini was intending to look at running self hosted runners #2247 on Build WG administered infrastructure but AFAIK that didn't get anywhere. Realistically I'm not sure the current active members of the Build WG has the capacity to expand our infrastructure beyond what we currently have running.

Setting up jobs in our Jenkins instance is an option. We used to have Jenkins jobs for llnode but those went stale through not being used and were earmarked for removal last year #2619 (comment) -- I removed them back in April. We have backups, so they could in theory be restored (but tbh given that at least one of the jobs was testing on Node.js 6 and 7 it's probably better to start afresh). I'm not sure though if we'd still need new VMs as I think most of the existing VMs in our CI are 4GB RAM.

Some remnants of the deleted llnode jobs are in this repository:

• https://github.com/nodejs/build/blob/main/jenkins/scripts/llnode-continuous-integration.sh
• https://github.com/nodejs/build/blob/main/jenkins/scripts/common/getLLDB.sh

[mhdawson]

If a Jenkins job would work, then I agree that is the easier way to go.

[No9]

Hey @richardlau Thanks for getting back with all the detail so quick.

Totally understand that the Build WG does not have the capacity to expand the infrastructure with the self hosted runner option.

Looking into this a little further I see that resizable github hosted runners are in beta and due out in Q3.
github/roadmap#161
I think this would be ideal for our scenario it would mean we can keep our current CI config and don't put any additional strain on the project from an infrastructure management perspective.

Couple of questions you might be able to help with:
Does the nodejs GH org have credits in place that could pay for this feature when it comes on line?
Do we know anyone in GH that can enable the beta feature for the llnode repo?

If we can get the credits for this then worst case scenario we wait for the feature to be made GA.
Otherwise we can start looking at the jenkins scripts.

[richardlau]

Couple of questions you might be able to help with: Does the nodejs GH org have credits in place that could pay for this feature when it comes on line? Do we know anyone in GH that can enable the beta feature for the llnode repo?

If we can get the credits for this then worst case scenario we wait for the feature to be made GA. Otherwise we can start looking at the jenkins scripts.

I don't know. @mhdawson any ideas?

[mhdawson]

Couple of questions you might be able to help with: Does the nodejs GH org have credits in place that could pay for this feature when it comes on line?

[mhdawson]

Does the nodejs GH org have credits in place that could pay for this feature when it comes on line?

Yes but I'd be concerned about running out as just making sure Microsoft tops up our credits to keep our existing windows testing going has been some work. Short answer is I'd prefer not to.

[No9]

Thanks for the follow up Michael.
So the topic of project financial support is outside the scope of this issue so it's best to say adding more resources to GH Actions isn't an option.

As immediate next steps llnode will continue to review the tests to see if the stability can be improved.

@richardlau If we do need to move to Jenkins do I just PR updated versions of those scripts back in and ask you to configure?