search

yao-pkg / pkg-binaries

Collection of pkg nodejs binaries that are not supported by pkg
MIT License
89 stars 23 forks source link

macos-x64, win-x64, alpine-x64 and linux-x64 binaries #10

Closed n1ru4l closed 1 year ago

n1ru4l commented 4 years ago

Would also be nice to have those over here as pkg-fetch repository is only infrequently maintained.

macos and win binaries must be built without docker buildx as there is no way to emulate that. Fortunately, GitHub actions does have support for both macos and win. Because of that the build should also not take that long and require a custom builder.

robertsLando commented 4 years ago

:+1: For that, would need to work on github actions and runners... If the build ends in less then 6 hours we could remove the custom runner and use multiple github runners. Now It would be better to publish other os (alpine mac win) in a dedicated release.

What do you think?

n1ru4l commented 4 years ago

I actually don't mind all binaries being listed on the same release. This gives you a quick overview of all available os/arch/node-version combinations.

Not requiring a self-hosted Github Action runner would be super cool!

robertsLando commented 4 years ago

I'm wondering if github has some sort of limits in assets for a release

robertsLando commented 4 years ago

Seems not: https://docs.github.com/en/github/administering-a-repository/about-releases#storage-and-bandwidth-quotas

n1ru4l commented 4 years ago

Check https://docs.github.com/en/github/administering-a-repository/about-releases

EDIT: Oh you were quicker :D

robertsLando commented 4 years ago

Ok so feel free to go on with this, happy to review any pr :rocket:

n1ru4l commented 4 years ago

We could also do one release per Node version, that would be more overseeable

robertsLando commented 4 years ago

We could also do one release per Node version, that would be more overseeable

Sure! We could create one for each node lts: Node 8 Node 10 Node 12 Node 14

robertsLando commented 4 years ago

We should create a tag for each node version (pointing random commits) and use tags in the format node-<nodeMajor> that will be placed here

n1ru4l commented 4 years ago

could also create one release per Major.Minor.Patch tbh

robertsLando commented 4 years ago

could also create one release per Major.Minor.Patch tbh

Humm I don't think that's a good idea, for what I see there are just few versions for every major (as you said pkg and pkg-fetch aren't updated a lot). I think that separete node majors would be enought

n1ru4l commented 4 years ago

https://github.com/vercel/pkg-fetch/releases Groups by pgk-fetch version. There could also be a difference on whether the binaries are compatible with another pkg/pkg-fetch version or not 🤔

robertsLando commented 4 years ago

I know but I never expected issue when using binaries made with a different pkg-fetch version

robertsLando commented 4 years ago

We could ask, maybe we will have an answer in next years

robertsLando commented 4 years ago

@n1ru4l If you want I could create the tags/releases we spoke about. Are you ok so to have node10 node12 node14 tags?

n1ru4l commented 4 years ago

@robertsLando yes!

robertsLando commented 4 years ago

Done

robertsLando commented 4 years ago

@n1ru4l I have moved the binaries from the old release to the new ones, please give it a check I didn't miss something (except the node13 that I skipped on purpose). Anyway I will also leave there the first release as some users may have scripts pointing there to download the binaries, will remove it in the future maybe or we could keep that for not LTS node versions