Support non-semver tags

[RomeroGaliza]

I think it would interesting to decouple the idea of "semver" from "tag" in this resource.

Docker image tags are not always versioned, for example, one could simply use a commit ID, or whatever string you like.

As far I my research could go, this assumption (in which all docker images are versioned and following semver) is not supported by any official documentation.

We could keep the present behaviour (as default) and perhaps add a param variable to flag whether the tag is following semver or not.

What do you think? Would that be an improvement?

[ChrisJBurns]

I agree with this. I've been on projects where the image tag was the first 6 characters of a commit hash where used with a suffix e.g. 3bd8a5-dev.

Would like to see this implemented here if possible as I only just saw that it wasn't supported.

[parmsib]

We have run into this as well, with the tag latest, no less.
Our use-case was that we wanted the check to return only semver tags, but it was also returning latest, even as the last tag.

From the wording in the README:

With tag omitted, check will instead detect tags based on semver versions (e.g. 1.2.3) and return them in semver order.

it seems to me that it should thus not detect tags that are not based on semver versions, although both the phrases "detect" and "based on" are a bit unclear here. This part of the README led us to believe our use-case would be satisfied by just not specifying a tag.

Workaround
We found that adding a semver_constraint of >= 0 acted as a constraint that the tag must be semver-versioned at all, and thus excluded the latest tag, which was the behaviour we were after. This is, AFAIK, the best way to get all semver tags.

On the latest tag
While dealing with this, we also realized that the image of the resource itself has not updated its latest tag for about a year, according to docker hub, which we were unaware of. This led to us using an old version of the resource while thinking we were always using the latest, as we had specified the latest tag for it. I have a suspicion that this is the case for a lot of people, who are still unaware that they are not continuously getting the latest version.

[loksonarius]

Just got bit by this myself just now.
In my case, I expected some tag filter source option. Specifically, I had expected something functionally equivalent to the tag_filter option used in the github-release resource.

Now I'm left figuring some other way of getting new versions out of the k8s.gcr.io/dns/k8s-dns-node-cache image 😅

[ChrisJBurns]

Is there any official response from the Concourse developers? Quite concerning that the recommended resource that we're being told to use doesn't have the functionality that a lot of people will want, and the issue that is raised to point that out has been ignore for almost a year.

[cdmessin]

There now exists a tag_regex param that you can add to the source configuration. The README describes the usage of this in more detail. In short, you can monitor for whatever you want. If you wanted to get all tags from a repository, you could use tag_regex: ".*"
Or if you wanted to monitor for something like the git hash example you mentioned @ChrisJBurns, you could use something like tag_regex: ^[0-9a-f]{6}-dev$.
This is currently available in the dev tagged image of the registry-image-resource, that you can use and test with by overriding the bundled version like so:

resource_types:
- name: registry-image
  type: registry-image
  source:
    repository: concourse/registry-image-resource
    tag: dev

You'll have to keep an eye on this repo's releases and that registry for whenever the next official release happens. At that point, you could change the tag above to that version. I'm not an official concourse developer, so I have no insight into the release cycle. After that, it seems concourse itself also needs a release to change the version of the default bundled registry-image-resource if you wanted to remove the custom resource_type override entry.

[ei-grad]

Having "tag_regex" specified doesn't help to push the built image into the registry:

ERRO[0000] invalid semantic version: "0.3.0b0"

Is this code really needed? https://github.com/concourse/registry-image-resource/blob/master/commands/out.go#L86-L93
IMO this logic is completely unrelated to the registry-image-resource functionality, and should be just removed.