jtackaberry
commented
8 months ago Since you've always just upgraded the chart unconditionally when a new release comes out
Not entirely unconditionally. I do some quick sanity checking with that version in a test cluster before updating the chart.
would it make any difference to just set it to the "latest" version (assuming that is possible)?
It's technically possible to set the default tag value to latest instead of the actual version but this means that the same chart version can result in different deployments at different points in time, which violates the Principle of Least Astonishment. Best practice is to pin versions, and if users of the chart want to YOLO their rqlite deployments then they can explicitly set image.tag to latest at their discretion (and risk).
This is how charts typically work, and normally it's not that much of a problem, you're just on a tear wrt rqlite releases. :)
There's also nothing saying the chart has to always track the latest app version, so I really just rev it when time permits, so although it's toil by definition, it's not particularly onerous right now.
The ideal solution would be to setup a scheduled GitHub action to automate looking for new app versions, do a test deployment of the chart in some cluster, run some basic smoke tests, and generate a commit to trigger the release action. I may look into this at some point this year.
Thanks for jumping on this.
This seems like it is going to result in a lot of toil going forward. Since you've always just upgraded the chart unconditionally when a new release comes out, would it make any difference to just set it to the "latest" version (assuming that is possible)?