Open cfryanr opened 8 months ago
While running the above pipeline, I noticed that during the day yesterday the golang-image
resource had a latest
version. But by the time the job auto-triggered at 1 am that night, the latest
version was gone from the resource and the job passed. So a better reproduction pipeline would auto-trigger the job more often to catch the problem while it is happening.
Describe the bug
When creating a resource like this:
I would expect that the only versions detected of this resource would be semver version numbers, as described in https://github.com/concourse/registry-image-resource#check-step-check-script-without-tag-or-tag_regex-discover-semver-tags.
When initially creating the pipeline, this works as expected. The only versions initially detected for this resource are semver numbers.
However, after the pipeline has been running for some days, eventually the version tag
latest
appears in the resource's list of versions, even thoughlatest
is not a semver version tag. This confuses any job which was expecting the resource to behave as documented, and can result in incorrect behavior of jobs in a pipeline.For example:
Note that in the above screenshot, the digests of
latest
and1.21.5
do not match. This is because the golang image for tag1.21.5
on dockerhub really does change its digest every few days/weeks. This unfortunate behavior of this particular container image might be contributing to the bug.Reproduction steps
The following pipeline should reproduce this behavior.
Expected behavior
I would expect the the
golang-image
resource described above would never detect a version forlatest
becauselatest
is not a semver version number.Additional context
Maybe it is related to this other reported bug? I'm not sure. https://github.com/concourse/registry-image-resource/issues/316