I'd keep striving to get Alpine 3.4 working tbh – it adds a bunch of very useful stuff for ppl in environments like Kubernetes and it'd be easier to deal with just one version of Alpine. Node.js definitely builds on it, I guess it's just a matter of finding out what's going on in this env.

I know very little about the nodejs build environment, so it'll take some digging to figure out how things are setup

I explored the tests a while ago and found some reasons they were failing:

nodejs/docker-iojs#44 (comment)

Two of the failures (parallel/test-net-better-error-messages-port-hostname and parallel/test-net-connect-immediate-finish) are AssertionError: 'EAI_AGAIN' === 'ENOTFOUND', which are being discussed in nodejs/node#5099 and nodejs/node#5196.

I'd also be interested to see if, instead of having to build inside of Alpine, you can just build with musl instead of glibc – technically I think that should work. (I believe this is what rust does, for example)

(actually, that idea doesn't really address the testing-in-Alpine aspect, so it's probably of only limited value)

Updated to Alpine 3.4 thanks to @mhart's pointer.

Here's a run on master: https://ci.nodejs.org/job/node-test-commit-linux/3803/nodes=ubuntu1604_docker_alpine34-64

Only 3 failures:

parallel/test-net-better-error-messages-port-hostname
parallel/test-net-connect-immediate-finish
parallel/test-setproctitle

@rvagg the setproctitle one could possibly be fixed by adding procps to the list of apk packages to install – apparently that allows support for the -p flag. Whether or not that's a good enough solution, I dunno. I'm not sure why the test has to specifically rely on that flag being supported though – perhaps it could be changed to something else?

great, procps has done it, updated Dockerfile and we're down to just the EAI_AGAIN' != 'ENOTFOUND' errors https://ci.nodejs.org/job/node-test-commit-linux/3804/nodes=ubuntu1604_docker_alpine34-64

After some digging I discovered that the preferable way to run Node in Alpine is to build it in alpine rather than reusing binaries that we build for generic Linux

It's not possible to build Alpine binaries in CentOS unless you use a cross compiler. CentOS (and almost any other generic linux) uses glibc, Alpine uses musl.

So this is a continuous integration part (point 3 in #301 (comment)), right?
Would it be trivial to port this to other versions of node?

I think we need bash as requirement

I guess its worth mentioning that we now have full alpine passes through both docker instances and joyent's virtualization.

We should probably update to Alpine 3.5. There's also a few new Ansible modules for managing (building/running) docker containers we can replace the shell commands with. I see both as optional before merging though.

We should probably update to Alpine 3.5.

Alpine 3.6 is released, FWIW.

alpine is in the new ansible/ stuff so I'm assuming it's good there, I haven't used it myself though

Is there a generic issue for tracking a build of node for alpine? Or should I just watch #989?

New version of this in #992, that's what's active in CI now with Alpine 3.4, 3.5 and 3.6 running in node-test-commit-linux. I've taken the old test-digitalocean-ubuntu1604_docker_alpine34-x64-1 host out of rotation, it was set up according to this PR and has been running our Alpine 3.4 tests till now.

@SimenB this might be what you're looking for? #75