Skip to content
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

TODO: Upgrade Alpine base #26

Open
rvagg opened this issue Mar 18, 2021 · 4 comments
Open

TODO: Upgrade Alpine base #26

rvagg opened this issue Mar 18, 2021 · 4 comments

Comments

@rvagg
Copy link
Member

rvagg commented Mar 18, 2021

This is a TODO for someone who wants to change the recipe Dockerfiles to make them work with newer Alpine, and test that they can still build Node.js properly. fetch-source, musl and headers all use FROM alpine:3.9. To test an upgrade, you'd need to switch the FROM, build images, then run containers in a way that executes their build tasks. It might be a little involved to make it work locally but hopefully by looking at the recipes it's not too unclear what needs to be done (fetch-source is a special case recipe that's run before all the rest that simply downloads and unpacks the tarball).

I think it would be safe to upgrade to 3.12, they're based on musl 1.1.x (see). while 3.13 jumps to 1.2.x(see).

We don't have a strict contract here for libc versions or any minimum level of support across major versions. We also don't currently have a mechanism to switch recipes based on Node.js major versions. So I think for now we could just do 3.12, cross our fingers a little and hope that we still produce maximally compatible binaries. Then we can make the 1.2.x jump a bit later when the ecosystem has moved on a little. The musl ecosystem is largely made up of Alpine (tho there are more), and Alpine users tend to be on much quicker upgrade cycles so give it 6-12 months and we could probably make a decent bet that folks have moved on and then we can switch to a newer Alpine with 1.2.x.

/cc @nodejs/docker

@LaurentGoderre
Copy link
Member

Would be ok to produce both versions until we know that the new one works?

@rvagg
Copy link
Member Author

rvagg commented Mar 31, 2021

how would we name them? how would we get people to consume and test the new ones?

@LaurentGoderre
Copy link
Member

We could use the new one in the docker image. It would be a lot less risky to upgrade if we have the other version to rollback to if there's a problem

@mckaygerhard
Copy link
Contributor

i thinks using a newer base apine is pointless cos thi project try to compile for unsupported targets, alpine already have a official package for nodejs,

so in fact is right choose using an older alpine docker base for buils so will sure the backguard compatibility with all older or midlle-recent alpine unsupported targets

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants