Using container repositories (DockerHub, QUAY) to automatically build images via webhooks works great when there's one container/Dockerfile per source code repo (e.g., GitHub). However, hosting multiple containers in a repo can be problematic for several reasons:
Any new commit pushed to the repo will trigger builds for all containers connected via webhooks. This can be slightly mitigated by restricting builds to specific branches or tags, but will still result in all images being built (just less frequently).
Because image tags in DockerHub or QUAY are derived directly from the connected GitHub repo's tags, it's impossible to specify different tags/versions for individual containers. All containers will share the same tag/version, which is the tag/version for the repo.
Container repository build services might have hard limits on the number of concurrent builds triggered via webhook. While this is hard to track down in documentation, we recently encountered an error that suggested that this limit in QUAY might be 20.
Using a Travis job to build and publish a container image (via docker push) might allow for more fine-grained control of build jobs and tags/versions. We should look into how this might work in practice, and maybe set up a small example.
Using container repositories (DockerHub, QUAY) to automatically build images via webhooks works great when there's one container/Dockerfile per source code repo (e.g., GitHub). However, hosting multiple containers in a repo can be problematic for several reasons:
Using a Travis job to build and publish a container image (via
docker push) might allow for more fine-grained control of build jobs and tags/versions. We should look into how this might work in practice, and maybe set up a small example.This post looks like a nice place to get started: https://adriankoshka.github.io/blog/posts/travis-and-quay/