Hi @faulpeltz and thanks a lot for this PR!

I was able to get all builds to work except macos-arm64, because it times out or crashes with out of memory on the GH actions workers

I was having the same issue in #40, I fixed it by reducing job counts to 2, try using 1 maybe?

@faulpeltz New majors usually require some work on pkg side too, would you mind to open a PR there and reference this?

Hi @faulpeltz and thanks a lot for this PR!

I was able to get all builds to work except macos-arm64, because it times out or crashes with out of memory on the GH actions workers

I was having the same issue in #40, I fixed it by reducing job counts to 2, try using 1 maybe?

I tried setting it to 1, but then it runs into the 6h build time limit

@faulpeltz New majors usually require some work on pkg side too, would you mind to open a PR there and reference this?

Didn't change anything for now, will open a PR as soon as there are any changes

@faulpeltz About macos-arm64 you could try to use macos-14 runner as it's ARM64, you can then remove the compiler env vars (also rememver to change the arch check step at start to check for arm64 instead.

@faulpeltz About macos-arm64 you could try to use macos-14 runner as it's ARM64, you can then remove the compiler env vars (also rememver to change the arch check step at start to check for arm64 instead.

no luck with the macos-14 runner, setting jobs to 1 helps but it seems to run out of disk space every time

Thanks for giving it a try, I'm sincerly out of ideas about arm64, I have lost a week tring to make it work for latest images, I think the problem is that each new major version requires more resources so the error happens. If you are aware of any build flag and/or env that could help mitigate the issue let me know. For what I saw x64 cross build still preforms better then the native arm64 in terms of RAM so I would restore it for now and work on that.

The alternative could be to use the -large runners but I don't think them are free to use

@faulpeltz thanks so much for all the explainations 🙏🏼 Do you think this can be merged and released?

@faulpeltz I would disable arm64 build on nodejs 22 for now as we need it to end successgully otherwise the build all job will not end successfully and I cannot do a bump

@faulpeltz thanks so much for all the explainations 🙏🏼 Do you think this can be merged and released?

I think we can merge it, but maybe make some sort of prerelease or release Node 22 as experimental because I think this should be tested by the community.

I'll just clean up history and remove the arm64 macos build for now

I think we can merge it, but maybe make some sort of prerelease or release Node 22 as experimental because I think this should be tested by the community.

I would make a normal minor release of pkg and tell on changelog that node 22 support is experimental

Let's see how this goes: https://github.com/yao-pkg/pkg-fetch/actions/runs/10789654031

Let's see how this goes: https://github.com/yao-pkg/pkg-fetch/actions/runs/10789654031

I just saw this issue in the main NodeJS repo:
nodejs/build#3878

We could try this for pkg fetch builds as well

@faulpeltz do you mean:

https://github.com/nodejs/node/pull/54658/files ?

May be worth a try, yeah! :)