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:

• Make resource aware of new release tags #144
• Tags are pushed even when not needed #129
• Push src and tags should happen separately, and in that order #110
• Push src and tags should happen separately, and in that order #110
• Tag behaviors should work for detached HEAD tags #74
• I would like to be able to ignore tag-only commits #91
• New tags are not found in tasks and jobs after the put #94
• Request-for-comments: Add git tag signature verification #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.