Build suite

[retrohacker]

• Break builds into multiple stages
• Smoke test against several popular npm packages
• Only print logs of npm test and npm install in the event they fail, otherwise just print that they ran.
• Parallel builds to make better use of network
• Captures the version of npm, node, and all deps (also ensures they are executable)

[retrohacker]

An example of this running: https://travis-ci.org/retrohacker/docker-node/builds/120795720

[retrohacker]

All tests passing. Ready for review.

[chorrell]

I'd like to know how long this takes in TravisCI with the current variants, tags and images. I ran this locally but it seemed to take a while (like 30+ minutes before I gave up). I'm assuming it would be faster in TravisCI though.

[retrohacker]

@chorrell https://travis-ci.org/retrohacker/docker-node

23 minutes

[chorrell]

Ah, ok cool. That's reasonable my underpowered MacBook probably isn't representative of a test run...

And I completely overlooked that it was already run via travis in your account.…

So where are we at now if we want to merge this? I think the one open item was what to do with inventory.yml.

[retrohacker]

@chorrell just landed 😄

Once the tests pass, this should be ready to land if we can get a few 👍s

[retrohacker]

One of our smoke screen modules started failing tests... Perhaps we should pin to specific versions as opposed to master?

[pesho]

So where are we at now if we want to merge this?

I'm a bit confused, honestly. Such extensive smoke testing is certainly very useful, but does it really belong in the Docker WG?

• The tests check Node itself, not so much the Docker image. So, aren't they more within the scope of @nodejs/build or @nodejs/release?
• For most modules, the master branches are targeted. Bugs which slip there (it happens occasionally even with popular modules) would case test failures due to no fault of the Docker WG.
• From a certain point of view, the real target of the tests are the modules themselves, not Node and not the Docker image. If a Semver-major Node release has a breaking change, some of the modules could be slow to follow and fail some tests. Should we then not make releases?

[retrohacker]

@pesho totally valid.

The tests check Node itself, not so much the Docker image. So, aren't they more within the scope of @nodejs/build or @nodejs/release?

Yes, but we want to ship an Alpine image which isn't supported upstream. This would require us to take on the burden of testing this. Happy to ship that upstream if it is of interest, but not willing to ship an Alpine image without being able to certify the Node.js binary is behaving as expected in that environment.

For most modules, the master branches are targeted. Bugs which slip there (it happens occasionally even with popular modules) would case test failures due to no fault of the Docker WG.

Absolutely. Smoke tests are my attempt at saying "popular modules work with Node.js in this environment" for lack of a better way of testing... If you have a better idea I would love to throw away smoke tests.

From a certain point of view, the real target of the tests are the modules themselves, not Node and not the Docker image.

Absolutely. Again, smoke tests are less than ideal, but I can't think of a better solution. Perhaps finding a way to run the whole test suite? But that would seem a bit unfair to TravisCI.

[pesho]

@retrohacker thanks for explaining 👍

Yes, but we want to ship an Alpine image which isn't supported upstream.

Yes, I'd like that as well. Can you clarify (if you know), what is the exact reason it's not supported upstream:

• Is upstream (Node) fundamentally opposed to providing an uClibc build?
• Or, is it rather that nobody has done the work yet?

[rvagg]

I did start tinkering with this last week, I wanted to try make a CI slave that did a CentOS5 build in a Docker container and then run that binary in an Alpine image. That would mirror how these binaries would (probably?) be used in the wild since our nodejs.org binaries are built on CentOS5.

Am I assuming right that nobody is actually building on Alpine?

[retrohacker]

@rvagg based on my experience, that is a safe assumption (though people have been known to do crazy things). Testing a precompiled binary in an Alpine image upstream would be good enough for me to sign off on putting it in an image here 😄

The main concern will be libc and getaddrinfo. We have two paths forward:

1. support a statically linked image upstream that addresses the libc issue
2. install linked deps in the docker wg's alpine image

2 seems like the easiest path for us based on our luck statically compiling node in the past...

[rvagg]

so what does that actually mean? you have to install a full libc in Alpine images to make it fully work?

[retrohacker]

Yes, I believe this is what will be necessary. I need to look closer at mhart's work here though: https://github.com/mhart/alpine-node/blob/master/Dockerfile

[rvagg]

Discussion and preliminary CI support @ nodejs/build#437, this is going to need some help from you folks if we're to make this work. The test failures will mean we can't keep it in CI.

[retrohacker]

We shipped Alpine. Think it is safe to close this PR.