Open alexellis opened 2 weeks ago
I'd favour the concept behind the psql.image
. The question I have around this is what other attributes are we likely to want to hold? If its just the image then the reducing the redundant information in hold will improve usability.
Naming convention ought to be that it follows the filename passed by -f
suffixed with .hold
.
Expected Behaviour
I want some container images to be updated, and others to be pinned.
i.e.
postgres:16
should stay at16
, not go to17
when it happens to be available.Current Behaviour
When a specific container image is actually wanted, even if newer ones are available, it gets upgraded anyway.
Possible Solution
A new file adjacent to the values.yaml with some convention for its name could be read and used to know to ignore that YAML path / selector / image.
Given the following, you may want to have one upgrade, and the other hold, in which case you need the full path to the image tag.
But more likely the image only appears once, and only needs one version, so perhaps the image itself could be specified.
hold.txt - specifies path in YAML to field to hold one per line
hold.txt - specifies the specific source tag to ignore one per line
hold.yaml - specifies the same format 1:1 as the values.yaml, and the presence of anything in it means it's ignored:
Steps to Reproduce (for bugs)
arkade chart upgrade
See it upgraded from 16 to 17
Context
We are maintaining postgresql for certain charts with images that do need updating regularly mixed with ones which do not like Postgresql, and this has become tricky to manage.