Git Tag Feedback


The new Git Tags support for CircleCI 2.0 is a much-awaited (and much needed) addition.

The documentation for Git tag job execution runs through a number of examples, but it’s not clear from the examples how the satisfaction test is performed. In particular, does each job need to declare compatible tag filters in order for a dependency chain to work properly?

Build on tag


Thanks for your feedback.

does each job need to declare compatible tag filters in order for a dependency chain to work properly

Yes. Each job and its transitive dependency that runs as a part of a tag push must have a filters -> tags section.

Please also note that having tag filtering, does does not preclude the job from running on a branch push. That is to say, our approach when looking at whether a job should run is:

  1. For an unrecognized branch push, we run the job.
  2. For an unrecognized tag push, we skip the job.

In the documentation section you linked seems to still cause some confusion.

Git tags must be declared in each job and in the workflow. CircleCI will not run a job for a Git tag unless some kind of tags filter is specified.

We are working to highlight this ^^ point.


I’ve opened to address the confusion. @DavidAntaramian Do you think this is clear enough?


It answers the question, but I find the design to be needlessly complicated. This follows my feedback regarding workflows overall. Circle is conflating the high-level concern of “What type of build should this be?” with the lower level concern of “What are the steps necessary to complete this build?” I should not have to declare a tag filter repeatedly on separate build jobs, especially transitive jobs. A tag should activate a specific build configuration (or, in CircleCI 2.0 terminology, a “workflow”), and that build configuration should define the necessary steps (and their parallel qualifications).


Thanks for the feedback.

We will iterate on the config and already have some ideas to simplify it. The explicit version will work for the foreseeable future.


I agree with @DavidAntaramian that the feature is nice. The defaults, however, are rather confusing. Quoting the documentation:

My suggestion would be to treat branches and tags the same. In our workflow we usually tag commits because we want a build.


This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.