tracking tags

[jtarchie]

The git resource is trying to do too much. Supporting tags and branches with their workflows is polluting the git resource with lots of conditional logic.

I'd like to start a discussion of extracting tag logic from the git resource. That way we can isolate different workflows.

Below is a collection of issues related to tags:

• concourse/git-resource#144
• https://github.com/concourse/git-resource/issues/129
• https://github.com/concourse/git-resource/issues/110
• https://github.com/concourse/git-resource/issues/110
• https://github.com/concourse/git-resource/issues/74
• https://github.com/concourse/git-resource/issues/91
• https://github.com/concourse/git-resource/issues/94
• https://github.com/concourse/git-resource/pull/138

Maybe it is a resource, maybe its a motivation to destroy all tags, etc. TBD...

[bleach]

I'm interested in how this would work for our use case.

We make use of tags in our continuous deployment pipeline for Cloud Foundry. We have two concourses, each running the same pipeline. Our staging concourse adds tags to commits from master if tests pass and a tag filter on our prod concourse ensures that only tagged commits get applied.

Would this be possible if the tag logic were moved out of the git resource?

[nbering]

While experimenting with my own concourse workflow, I have found - while using the Semver resource - that tracking the version tag with a separate resource causes a lot of concurrency problems between resources.

Specifically, since the Semver provider doesn't really know that it's version number comes from the same git commit as the git resource, the build triggers before the two resources are "in sync". It would be great if a resource could use another resource as a dependency, but this doesn't seem to be supported by concourse's design.

Would love to be told I'm wrong.