Alpine continuous integration for Julia

[ghost]

I think Alpine Linux is a great candidate for continuous integration because it isn't gnu-centric like most distros and so helps test some edge cases like busybox utils, grsec kernel and musl libc compatibility.
It's also very small - 90 MB iso image (x64), 75 MB (x86) and 40 MB (generic arm).

ncopa asked for travis-ci to support it - travis-ci/travis-ci#6128
Even though they aren't going to do it any time soon, they presented a good substitute solution that may be enough for Julia use case.

[tkelman]

It's not a bad idea, but I don't think we'd want to add something to our Travis matrix for it (the queue is too long already). There are lots of other CI services around, competitors to Travis, that let you run from pretty much any arbitrary docker container (where alpine is even tinier, since it's just userland). Wercker, Shippable, Circle CI, Drone, etc all support running from a docker container of your choice I believe. I was already planning on moving our (glibc) 32 bit linux testing away from travis and onto Circle CI if I can get it working, so I'd slightly prefer if you started with a different service for experimentation.

I'd prefer if it were set up as a source build with zero patches if at all possible, building as many of Julia's dependencies in the exact configuration that our makefiles specify - supporting special distro system-libraries builds is a bit out of scope to do on every commit and pull request, I think the distros should be responsible for any ways in which their builds differ from what you would get from make in a clean source build. I realize LLVM and a few others still have messy patches for musl that haven't been upstreamed yet, but we can work on those on a case-by-case basis.

If you can demonstrate something working on your fork, and it won't make our existing CI queue any worse, then we'll certainly consider it. The route I would take is pre-building the deps via make -C deps install-foo and saving that into the docker image, then on the per-commit / per-PR build, you check out the specific commit or PR merge reference that the CI build specifies. That should keep non-test time to a minimum.

Another option would be setting up buildbot on dedicated infrastructure, but we use that more for building binaries or running on architectures that existing CI services don't support. I think most of our buildbots are running on the MIT openstack cluster and I don't know whether they even have Alpine images.

[ghost]

Setting this up is above my paygrade, I'll CC the expert :)
@jirutka what do you think?