Preliminary Alpine support for CI

[rvagg]

This adds a config for Ubuntu 16.04 + Docker that builds and manages an Alpine Linux 3.3 container which has the Jenkins slave running inside it.

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. Initially I started down the track of emulating our nodejs.org binaries by building in a CentOS 5 container before transferring to the Alpine container for testing. I scrapped that and went for everything in Alpine, assuming that we're going to ship images with binaries created inside them specifically for Alpine.

I'm using 3.3 because I had trouble getting 3.4 to run. It doesn't seem to like something about the combination of the mount point and the CMD and gives a weird sh error (su: can't execute ',,,:/home/': No such file or directory if anyone wants to chase this up).

It's temporarily in CI, you can see an example run @ https://ci.nodejs.org/job/node-test-commit-linux/nodes=ubuntu1604_docker_alpine34-64/3796 (the host is misnamed btw, it's "alpine34" but should be "alpine33").

Failures that we have are:

• parallel/test-net-better-error-messages-port-hostname
• parallel/test-net-connect-immediate-finish
• parallel/test-os
• parallel/test-process-getgroups
• parallel/test-setproctitle

If we don't have a path to resolving these fairly quickly then we should remove it from CI so collaborators don't get upset at all their runs failing. ATM I don't think we have a way of marking these tests flaky just for Alpine, it's done by operating system, not distro.

Where to next?

/cc @nodejs/docker @nodejs/testing @mhart

[mhart]

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

[mhart]

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

nodejs/docker-iojs#44 (comment)

[cjihrig]

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.

[mhart]

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)

[mhart]

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

[rvagg]

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

[mhart]

@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?

[rvagg]

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

[Vanuan]

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.

[Vanuan]

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?

[jbergstroem]

I think we need bash as requirement

[jbergstroem]

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

[jbergstroem]

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.

[SimenB]

We should probably update to Alpine 3.5.

Alpine 3.6 is released, FWIW.

[rvagg]

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

[SimenB]

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

[rvagg]

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.

[mhart]

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