Getting an artifact version from a semver file

[aegershman]

I'd like to dynamically specify the artifact version which is pulled from a maven repository. Specifically, I'd like it to be from the semver resource:

- name: deploy
  plan:
  - get: version
  - get: artifact
    version:
      path: version/version # pulls 'version' from the contents of the semver version file

Is this possible / a use case you would consider supporting?

[patrickcrocker]

Hmm... i hadn't considered something like that. What's the usecase that this would solve? When would you use this in your pipeline?

[aegershman]

This is a dang old issue, sorry.

Here's my best attempt to explain the rationale:

If we can get the version dynamically from a version file, the version file can be used as the source of truth to retrieve the artifact version. Then that version file can be stored in vcs, namely git, and treated as a "latch" to dictate what version of an artifact is used.

For example: I have a git repository structured as config for all my PCF environments. Each file represents the application artifact & version I'd like to have in that org/space:

config/
  sandbox/
    myapp-version.txt # contains "2.5.0"
  dev/
    myapp-version.txt # contains "2.5.1
  prod/
    myapp-version.txt # contains "1.0.0"

Now that the version has been externalized in a version file, I can:

• Promote the version of environment through pull request
• If I need to revert the version being pushed, I can do it in git. If we relied on Concourses' (current) resource flow (assuming no version pinning), we'd be stuck. We couldn't go back. Latest only.
• I don't have to rely on Concourse's passed: [] semantics for everything.
  • I can control the version of the artifact being pushed without forcing each pipeline job (one for each environment, like cf-push-sandbox, cf-push-dev, etc.) to be in the same pipeline. All you have to do is configure where each discrete pipeline should look for the versionfile, and it would treat that as the source of truth.
  • Plus, if you're using the passed: [] semantic, then if you lose the state of your pipeline (it gets reset), you're in bad shape. If you weren't ready to take the latest version in production just yet, but your sandbox job had the latest version, you can't go back. When you re-push your app to prod, it will take the latest because that's what passed sandbox.

In general, we try to have our pipelines be as stateless as possible && externalize "version" state to git wherever we can.

Does this make sense? I hope I did an okay job of articulating it. Willing to give more details if you'd like.

If this is something you don't intend on implementing anytime soon please feel free to go ahead and close this. Entirely your call 👍 thanks a ton

[lindenquan]

I hope version could take regular expression too.
It would be good if a pipeline just cares about release versions or develop versions only