Tell us about your request
Add the ability to specify a whitelist (or regex/pattern) of tags to specifically exclude from the tag immutability feature introduced in #169.
Which service(s) is this request for?
ECR
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Tag immutability has a lot of benefits for reliability, security, and compliance; however, it breaks certain workflows. For example, the common use of the latest tag.
Although using latest in production is an anti-pattern, there are multiple valid uses such as to use it in CI/CD builds as a Docker cache, or for dev/test workflows such as local development.
Ideally it would be possible to get the benefits of tag immutability in production without needing to sacrifice the flexibility of having some tags remain mutable.
Are you currently working around this issue?
As far as I know there is not a satisfactory workaround to this issue. One solution might be to maintain two registries (one with immutability, one without), but that would double storage costs and other overhead.
Another possibility discussed in #169 is to programmatically untag prior to pushing a new tag, but that would introduce a race condition whereby the tag is not available between untagging and pushing. If latest is being used in builds, for example, this would be a problem.
Additional context
There is some further discussion in #169.
This would be handy. Right now we disable immutability if any tag at all might need to be updated.
While we dropped all use of latest we do often use 'series versions', which is a common pattern for shared or public images. So will each build has a unique tag
1.2.101.2.111.2.12The newest version of 1.2.x is also tagged 1.2. This gives the consumer the options to always pull/check 1.2. or to lock to 1.2.11 and cache that image.
So if we could set a multiple mask regex of \d+\.\d+, we could support this use case.
This would be amazing for us, especially for use cases beyond latest.
For example, our CI/CD system tags our images in a predefined manner and we'd like only those tags to be strictly immutable, while allowing users to add/mutate any other tags they'd like.
As others have said, the ability to retag on some versions and no on others would be amazing. It would also be amazing to be able to set the number of tags required when creating a new image. Using the example above where there is 1.2 which would be tagged on 1.2.x we would want to require a minimum of 2 tags. Other examples such as official language images also include base image and base version so they would set something close to 7 tags on every new image with only the most specific of versions being restricted. But then you could say that having a regex map would allow for a mix of rigidity and flexibility.
Most helpful comment
This would be handy. Right now we disable immutability if any tag at all might need to be updated.
While we dropped all use of
latestwe do often use 'series versions', which is a common pattern for shared or public images. So will each build has a unique tag1.2.101.2.111.2.12The newest version of
1.2.xis also tagged1.2. This gives the consumer the options to always pull/check1.2. or to lock to1.2.11and cache that image.So if we could set a multiple mask regex of
\d+\.\d+, we could support this use case.