Add Docker files for building supported binaries

[nschonni]

In order to make producing binaries that aren't built by Travis or AppVeyor we could add Dockerfiles for platforms that we support

• Node-alpine
• CentOS
• Debian

Alternately a dynamic approach like https://github.com/lox/node-sass-build-alpine-binaries could be used

[xzyfer]

I like the idea of a build repo. We also don't have Debian specific binaries ATM but we maybe need them to resolve some segfaulting issues.

…

On 2 Jun. 2017 10:32 am, "Nick Schonning" ***@***.***> wrote: In order to make producing binaries that aren't built by Travis or AppVeyor we could add Dockerfiles for platforms that we support - Node-alpine - CentOS - Debian Alternately a dynamic approach like https://github.com/lox/node- sass-build-alpine-binaries could be used — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1996>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWHau50_3BZBamBnXe8ajwAyG1A9bks5r_1gTgaJpZM4Ntsy-> .

[nschonni]

@LaurentGoderre do you think it would make sense to do something like the Node-Docker repo?

[LaurentGoderre]

I would do a Docker build for all the variants if possible. Unfortunately it's not possible or easy to support Alpine at this time because Node doesn't report the compiler so it's more difficult to target MUSL

[saper]

@LaurentGoderre what kind of support would be needed from node to make it easier to get musl builds done? I think I have proposed something similar for Windows nodejs/node#6045 but for the unixlikes it might be more complicated.

[LaurentGoderre]

I would be nice from a Docker perspective to have Node officially support alpine as a platform (it's unfortunate we can't get per tags metrics for the Docker node images). Then it would probably be adding a property to the Process object that reports the compiler used to Compile V8. By default it would be glibc but for alpine it would be musl.

Ex:

console.log(Process.compiler) // musl

[LaurentGoderre]

I have had this in my head for weeks but haven't had the time to start the intimidating step to propose it to the community.

[nschonni]

@LaurentGoderre the linked repo at the top is how we currently do it. We know we're building for Musl/Alpine, and the loader has some sniffing to check if it should load it

node-sass/lib/extensions.js

Line 397 in bb45385

if (contents.indexOf('libc.musl-x86_64.so.1') !== -1) {

💯 that an officially supported way would be better 😄

[saper]

I have posted an update to the script https://github.com/saper/node-sass-build-alpine-binaries/tree/updates-2019

There is one thing that worries me though - is the g++ version we are installing using apk identical with what was used to build the node binary?

[xzyfer]

Probably not to be fair but it hasn't been an issue so far. I'm pretty nature even the 4.12 node 12 Linux binary was built with an older gcc without issues.

…

On Fri, 25 Oct 2019, 5:52 am Marcin Cieślak, ***@***.***> wrote: I have posted an update to the script https://github.com/saper/node-sass-build-alpine-binaries/tree/updates-2019 There is one thing that worries me though - is the g++ version we are installing using apk identical with what was used to build the node binary <https://github.com/nodejs/docker-node/blob/32db77882bb239753b554f35a232289fb0d30b56/8/alpine/Dockerfile#L12> ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1996?email_source=notifications&email_token=AAENSWAQRLED7LDCRUKOEMLQQHVGZA5CNFSM4DNWZS7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECGB6XA#issuecomment-546053980>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAENSWAA7FPYP7HYEK2CDF3QQHVGZANCNFSM4DNWZS7A> .

[saper]

I remember some mysterious alpine crashes that got fixed with alpine linux update.

I just checked 6, 8, 10, 12 and 13 images and libstdc++ versions do match with what we have in our build images, so we should be on a safe side now.