search

smebberson / docker-alpine

Docker containers running Alpine Linux and s6 for process management. Solid, reliable containers.
MIT License
596 stars 186 forks source link

Testing and automated releases #38

Open smebberson opened 8 years ago

smebberson commented 8 years ago

At present releases work as follows:

Note: I've turned of "automatic builds when a push happens" in Docker Hub. This is because when I'm pushing for say the alpine-redis image, the alpine-nodejs image also builds. This unnecessarily builds containers I don't intend on getting built and it also updates the timestamp on the :latest tag for other builds which is really frustrating.

Another note: because of the close inheritance of some of the images (which I think is a good thing), you then need to go through and test, bump version numbers, tag and release on Docker Hub downstream containers to take advantage of any updates. If you update alpine-base it's a big job! I haven't been doing this in one commit either so that I can keep the code in master as close as possible to the :latest release of any container. This makes things time consuming and hard to pull in great PRs such as https://github.com/smebberson/docker-alpine/pull/29.

It's not the greatest process at all.

I've thought of creating a build server and using Docker Hubs web hooks to automate the process a little more, but I just haven't had the time to implement anything and work through those issues above.

Also, I haven't seen much in the way of how to test and verify the state of a Docker image. It would be great to have them running through Travis CI. Especially when updating alpine-base for example, you could see at an instance what you've broken down-stream.

I'd like to create a discussion around this to see if we can streamline these processes a little.

smebberson commented 8 years ago

I've found some good leads for this:

@matthewvalimaki, do you have any other sources of information or potential routes to achieve this?

matthewvalimaki commented 8 years ago

@smebberson the first one looks awesome. I wonder though if we could use http://doc.gitlab.com/ce/ci/docker/using_docker_images.html with our own scripts? On that page I see bundle exec rake spec but no code. I think it's just a shell script returning proper exit code.

On that same note I wonder if we could use Gitlab runners feature to build & push more selectively than what hooks allow? For example query Docker Hub for existing releases and only build if tags/versions have changed in Github?

I have not used any of these features but they could provide a way to avoid any custom self hosted solutions.