[Feature Request] allow a flag to 'rediscover' previous versions

[bodin]

We wrote tasks that allow us to quickly roll back a deployment based on a previous version. We also track the currently deployed version so that we can restart / redeploy.

When we 'roll back' a version and push that version to a file using the git driver - the resource will not 'discover' it as new since the version has shown in the past.

version=1.0.0 
// Deploy New
version=2.0.0
// Roll Back
version=1.0.0 

After the last step - version correctly stores 1.0.0 but still reports 2.0.0 in concourse due to this behavior.

it returns the version specified in the file if it is equal to or greater than current version, otherwise it returns no versions.

I would like to propose an option like below

- name: version
  type: semver
  source:
    driver: git
    allow_duplicate_versions: true

If this is a feature that could be included - I can work on a PR

[vito]

:thinking: Maybe we should just have it always return the current version. To be honest I'm not entirely sure why we went with 'only return it if it's >= the current version' - it might just be an arbitrary version from 5 years ago when we first implemented check.

Having it always return the current version feels more accurate, since it'll always reflect the actual state of the world.

There might be some reason I'm missing though.

FWIW, it's not possible to record duplicate versions, since Concourse treats each version as unique keyed on its content directly.

[aegershman]

If it means anything we've had the exact same issue & as a result we sometimes swap out using the semver resource with the git resource, and then read in the contents of the version-file in a task. That way each new git commit sha is seen as "new", even if the semver itself is rolling back from 2.0 to 1.0, etc. It's definitely a workaround. If it could return the current version even if the "current" version is a rollback, that'd be pretty slick.

[bodin]

I would be good with 'just return the value in git'. With the ability to now pin resources to a version in the UI, I thought I would need this less. However, since if I reinstall the pipeline I lose previous versions, I still have a gap.

Thanks for the response

[aegershman]

As to vito's point about not being possible to record duplicate versions, wouldn't this require a different way to uniquely identify the "version" according to Concourse? e.g., 1.0 -> 2.0 -> 1.0 couldn't be stored in the versions: [] definition for the resource, it would have to be something unique for each, i.e. the git sha for the git driver. Then, even though the semver could be arbitrarily changed from 1.0 to 2.0 to 1.0 to 0.0-beta-0 back to 1.0 all day long, and the sha would be unique for each, so concourse would see each progression of those as "new". ... Right? Not sure how this would work for other drivers though. I'll stop pontificating about it since I don't know for sure, just putting out some thoughts 👍

[vito]

@aegershman It's OK for a resource to return a version which has already been saved; it'll just move to the "latest" position in the version history. So I think it'd be OK for this resource to just always return the current version.

FWIW, what you suggested would definitely be possible and would make it more obvious that the version has rolled back, since you'll have two versions in the history. I kind of like that idea, but it would only be possible for drivers which support versioning of the version itself. For git that could be commit SHAs, for s3 that could be done through a versioned bucket.

I'd like to re-assess the design of this resource in the future; there are a few subtle and odd things about it that I've run into over the years. Maybe when we get around to updating it for the new resource interface we can try and "do it right". One thing I'd like to explore more is having it be more opinionated about using git and perhaps even using git tags for all of the versioning. That way the versioning is kept all in one place and it doesn't require a commit to be made (which thereby changes the thing you're versioning).

[bodin]

I like the idea of using tags for recording the version, we are doing that now by keeping the version file outside the repository and using it on a put back on the source code repo. If the resource was able to directly work with tags on the source repo - that would be pretty cool!

We had used this plugin in the past for gradle, but dropped it for the support in concourse so we could apply versioning more broadly to our (possibly non-gradle) projects