Closed rabble closed 8 months ago
@cooldracula suggested a tagging scheme for this where:
latest
stable
tag that we manually change after a build has undergone QA and is ready to go to production@cooldracula did I get that right? Is this the right ticket for setting this up?
Basically, yah! To elaborate: every docker image can have multiple image tags. And so for any push to a branch of these repos, including main, we'd automatically make a new docker image with two tags:
latest
tag for us to validate and such.Then, if we do a tagged commit on main, following whatever sort of tagging structure we want (e.g. semver or date or dragonlance novels), we'd automatically make a new docker image with these tags:
Our production servers would automatically deploy the latest stable
tag.
The main thing i wanted to clarify is that on github we wouldn't be tagging releases as stable, that'd just be a convention on the docker side. This way, we can see and move through the progression of tagged releases in git, and revert stable
to an earlier git tag if we need to. This also means our server have an easy pattern for automatic deployment, while we keep the flexibility to deploy a particular image to a particular server if we need to.
infrastructure ticket #6, might be a better place for this, as I think you may be right that ghcr would be a better registry for doing this.
we host our images on github's container registry, ghcr, as it is easy to build as part of a github action, easy to find, and free.
So we're hosting our own docker repos