Maintain release images

WadeBarnes commented 1 week ago

When a release is created images are built and published to Docker Hub for that release. The images are not maintained following their release, meaning they are not rebuilt periodically to pick up updates (such as vulnerability fixes) made to the base container.

Create a scheduled maintenance job that maintains the last x (3 or 4) release images by rebuilding and republishing. The job should trigger at least once a month. This will help reduce the number of teams building and maintaining their own images.

Bonus points for:

Making the job(s) smart enough to know whether the base image has changed and only build the related images if the base image has changed since the last build.
Triggering the job(s) when there is a change to the related base image.

Other decisions that should be considered:

[ ] Should we continue publishing to Docker Hub?
[ ] Should we publish to the GHCR as well or instead of to Docker Hub?

WadeBarnes commented 1 week ago

cc @i5okie, @esune

mishraomp commented 1 week ago

vote for ghcr.io, and ref through artifactory

caggles commented 1 week ago

I would also be happy to discuss creating a service account with write access to the bcgov-docker-local repo in Artifactory where you can push backup-container images.

sheaphillips commented 1 week ago

vote for ghcr.io, and ref through artifactory

+1 for ghcr.io + artifactory.

jujaga commented 6 days ago

+1 For having the container image artifacts pushed to ghcr.io would be ideal, similar to what already exists on the hub.docker.io side. If we do swap over to ghcr.io, we do not necessarily need to continue having it be mirrored to dockerhub any longer, unless having it there makes it easier to mirror to artifactory. As long as the tagging for these image artifacts follows standard semver conventions it'll provide a huge value for downstream change management.

mishraomp commented 6 days ago

+1 For having the container image artifacts pushed to ghcr.io would be ideal, similar to what already exists on the hub.docker.io side. If we do swap over to ghcr.io, we do not necessarily need to continue having it be mirrored to dockerhub any longer, unless having it there makes it easier to mirror to artifactory. As long as the tagging for these image artifacts follows standard semver conventions it'll provide a huge value for downstream change management.

+1 for semver tag release,

BCDevOps / backup-container

Maintain release images #135