Description
Currently, we set the Docker image tag of stac-auth-proxy to be latest by default: https://github.com/developmentseed/stac-auth-proxy/blob/main/helm/values.yaml#L8
It seems like it might be nicer to pin the version, am just not sure what the best way to do that might be.
On other projects, we have used chartpress to build the docker image, tag the image and handle modifying the values files with the tag of the just-built image, like https://github.com/developmentseed/osm-seed/blob/develop/.github/workflows/chartpress.yaml
I feel adding chartpress is a bit of unnecessary complexity - it's really useful if one is building multiple images in the same repository, but I think it's a bit much just to handle the image tagging.
I think a question also is: Do we want to automatically publish a new Helm chart version with an updated Image tag every time we publish a new Docker image, OR do we want this to be an explicit / manual action to edit the image version in the helm chart?
Option 0: Do nothing, and leave the default image tag at latest
I do not like this option as this could mean that the image version running on a deployment could randomly change and it becomes hard to reason about.
We could make this the user's responsibility to pin in their deployment, but I believe we should have good defaults, and latest does not seem like a good default to me.
If we really want to do this, I might remove the default entirely and make image tag a required value to pass in, and then it's the users responsibility to handle choosing a stable version of stac-auth-proxy and updating when they want to.
Option 1: Automate updating of image tag in helm chart every time an image is updated
I like this as it keeps our latest helm chart up-to-date with the latest image. It does mean that we will then also update the helm chart for every new docker version (which I think is fine).
So far, we've used the chartpress tool to automate this on other projects. If we want this, I can do some looking around to see if we can find something a bit simpler, since chartpress also does a lot more that we don't really need.
Option 2: Explicitly update version in Helm Chart when we want to roll out a release.
This would make updating the Docker image + Helm Chart a two step process: push update to Docker image and build, and then update the default values.yaml in the helm chart with the new image tag.
This makes the helm release a bit more intentional and forces us to consider if we need to make changes to the helm chart for new changes in the application, etc.
I don't really like this either - we will forget, things will drift, etc. - I think it's better to have a good test suite for the helm chart, and just automatically update it to the latest docker image version.
Decision
I would go with Option 1 and just automate the version updating and pinning process. Will be great to hear if anyone has any thoughts on this, or experience with tooling to automate the docker tagging -> populating helm values (or an alternate approach). I imagine this is a fairly common use-case for projects where we are building the docker image and publishing the helm chart out of the same repository. We've definitely wanted this often and so far used chartpress - but I'm leaning away from chartpress for repositories that build a single image, so would look for an elegant way to do this.