-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request for large-runners on Github CI #45345
Comments
@anonrig the challenge with using GitHub runners in general is that they don't always support the OS versions we need or promise the stability needed to continue to support older Node.js versions. We would need to convince ourselves that for MacOS this is not the case. |
@mhdawson Replacing existing GitHub workflow runners with large ones will also be beneficial for contributors. |
FWIW status from me reaching out to GitHub is the same. I can follow up again soon here, but AFAIK they'll need to do some engineering to allow servers to run on accounts with zero balance. |
We discussed this in today's Build WG meeting (nodejs/build#3299) but GitHub runners are not really anything the Build WG can help with. I've removed the build-agenda label. Usage of large runners is linked to what is available on our organization in GitHub, which is managed by the TSC. I presume #45345 (comment) remains a blocker. |
@mhdawson What are the next steps? What do you recommend? |
@anonrig given what @bnb said about Github not being able to give us large runners due to due our zero billing I don't have a suggestion. My comment was that due to the requirements of our build GitHub is not going to be suitable our need to build/test on specific OS versions. It might be better if you track "achieve goal" X which larger runners being one option for that. |
@MylesBorins would you have a contact that it would make sense to talk to this about? |
@rginn We're trying to figure out how we might get access to GitHub's larger runners for actions. Is this something the Foundation can help with? Should I bring it to the CPC? Both? Neither? |
I'm chasing this down internally. |
We are currently using Github CI for
test-asan.yml
,test-linux.yml
,text-macos.yml
which uses the latest version on all of the workflows. Linux CI machines have 2 cores and macOS machines has 3 cores by default. Latest PR by @Trott shows that using-j3
instead of-j2
on macOS builds reduces the build time by 34 minutes (Referencing: #45340).There was a pull request open by @targos to use large runner (#44908) but later closed due to the unavailability due to Github internals (Referencing @bnb's comment: #44908 (comment)). @richardlau opened a different pull request for using large runners for
test-asan
(Referencing #45097), but closed it due toGithub's billing system
(Referencing: #45097 (comment))Due to the latest issues with macOS machines (referencing: nodejs/build#2917), I'd like to open an issue to keep track of the process of requesting and getting access to large runners on Github. Even though the issue with the macOS builds is not related to the GitHub machines, it might be good to rely more on Github hosts and less on the Jenkins hosts for macOS, maybe with the possibility of removing them entirely.
Even though I don't know what is the correct spec for the node.js builds, afaik the larger the core size, the faster the builds are done. Therefore I believe that getting access to 64 cores of large runners is appropriate for us. (For the full list: https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners)
cc @nodejs/tsc
The text was updated successfully, but these errors were encountered: