Renovate does not understand Docker images with no versioning #6913
Comments
rarkins
added
the
auto:reproduction
|
Please provide a public repo that reproduces the error |
|
BTW I think this is because you are using digests as your tag values and Renovate is attempting to sort these like versions. |
That makes sense. We use the Git commit SHA for our tagging rather than semver in quite a few of our base images. As a user, I wouldn't expect Renovate to assume that Docker tags are written in semver format and I think this is what is leading to unexpected results? |
|
Repro: CondeNast/renovate-issue-repro-6913#1 See log output in issue description. |
rarkins
changed the title
If Renovate can't sort the tags then it can't be used to update them. I suggest you disable Renovate for this image using a package rule.
You're in a pretty small minority with that expectation. Nearly all Docker images use some form of sortable versioning, for good reasons. Is it your expectation that Renovate always treats the latest published tag as the desired update?
e.g. update from commit SHA tags to kinda-versioned tags and vice versa? |
rarkins
added
reproduced: yes
type:feature
My expectation would be that if it's not a semver tag (e.g. the tag contains letters as well as numbers or exceeds a certain string length) renovate would most-likely ignore it completely, or possibly use the latest tag. Using the latest tag seems problematic for some scenarios where the tags are not properly versioned and could contain breaking changes, so I would recommend ignoring non-semver tags unless you have a better idea. That is of course assuming it is possible to invalidate the tag as being non-semver. Perhaps this is not possible if any string could technically be interpreted as valid semver string? I'm not sure whether or not that is the case. My feeling here is that renovate should avoid this behaviour out of the box if at all possible and we should not have to tell it specifically to ignore this dependency. I appreciate that this might be poor practice on the part of the maintainers of the Docker image but as a user (I personally am not the maintainer of this Docker image) this behaviour is quite difficult to identify and mitigate. |
|
For now we have disabled renovate automerge for |
|
I'm looking at some best practices docs on image tagging and there seems to be more of an emphasis on uniqueness and immutability over sort-ability. From Google's Best practices for building containers:
|
|
In practice it causes many difficulties, such as not being able to easily determine which version is newer. You can see they don't practice what they preach: https://hub.docker.com/u/google Anyway, Renovate does conceptually abort attempts to update if the existing version (in this case tag) does not satisfy what we expect the version to look like. Because Docker tagging is the wild west (and btw it's not just semver but also pep440 etc) our docker versioning scheme attempts to be very flexible - perhaps too flexible. I think we could add a special case that if an existing tag is a valid commit SHA then treat it as not a version and don't attempt to update it. |
rarkins
added
type:bug
|
Solution: in loose versioning, check if the string is a valid git commit SHA and return isValid=false |
|
@rarkins |
Will do 7-char hash as this is truncated version outputted from So I think this regex is a correct test for commit hash: (^[a-z0-9]{7}$)|(^[a-z0-9]{40}$) |
|
Should be Length 7-40 inclusive is probably most flexible too, i.e. One problem I see is that if people use date-based versions (e.g. i.e. matches |
What Renovate type are you using?
GitHub app
Describe the bug
We have found that Renovate has been downgrading the Docker image tag in our CircleCI configuration to a much older version of the image from a couple of years ago.
The image in question is hosted on quay.io and is a public image.
Renovate made the following change on 24 Apr 2020:
And this change on 29 Jul 2020:
Relevant debug logs
Log output from reproduction:
Log output
To Reproduce
See reproduction here: CondeNast/renovate-issue-repro-6913#1
The Docker image is specified in the Docker executor config in the CircleCI configuration.
e.g.
We are using the
config:basepreset with automerge enabled for minor/patch, and some other rules which are not relevant to the CircleCI deps.Additional context
Downgrading a Docker image tag in the CI configuration can pose a significant security risk if there are vulnerabilities in the older version of the image e.g. if the image was being used as a base image for a server app in production. In our case this should not be quite as risky since this was an image only for use in an internal pipeline.
The text was updated successfully, but these errors were encountered: