Job runs even when tags: ignore filter is triggered when combined with branches: only


#1

I have a staging build job with the config:

filters:
    tags:
      ignore: /v[0-9]+\.[0-9]+\.[0-9]+/
    branches:
      only: master

And a prod build job with:

filters:
    tags:
      only: /v[0-9]+\.[0-9]+\.[0-9]+/
    branches:
      only: master

The intent is that the staging job will run on all untagged pushes to master, and the prod build will run on all tagged pushes to master. Untagged commits will successfully trigger only the staging job. But when I push a tagged commit to master, both the prod and staging jobs run.

It seems like the staging job is only paying attention to only: master and disregarding the fact that it’s supposed to ignore tagged commits.

Is there a way to configure this properly?


#2

You need two workflows. One workflow for builds that have a tag and one for builds that do not have a tag. Please see the first example here: https://circleci.com/docs/2.0/workflows/#git-tag-job-execution


Workflows not showing when filtered to tags
#3

Are there just specific tags staging is suppose to ignore? Because if it’s suppose to ignore all tagged commits, then just leave it out of the config. The default for tags is to ignore.


#4

A post was split to a new topic: I have two work flows with opposite filters and both are run when I do a pull request. I would expect only ONE to run…


#5

I’ve just run into this issue and it seems pretty unintuitive and confusing given the config syntax.

It seems to me there is simply no way of saying “only run my my deploy workflow on a tagged commit to master.” Am I right in this conclusion?


#6

There’s no such thing as a tagged commit to master. Tags don’t have a branch.

You can use filters to only run on a tag and ignore all branches. This can be an individual Workflow or simply part of a single Workflow.


#7

So, how do I prevent someone from triggering deployment simply by pushing to a branch with a tag?


#8

(My apologies if I am simply misunderstanding git and/or github and/or what “tagged commit” means!)


#9

Tagged commits not having a branch is a Git thing. That’s just how Git does tags.

By not allowing them write access to the repository? I don’t have a better answer but I’ll see if I can share this with some colleagues.

@drazisil @levlaz Any ideas?


#11

I have run into the same problem here. This is a huge pain and I would appreciate any help. I have tried 3 scenarios and each creates double builds. Also, the builds do not show up in the workflows section, you have to select builds on the left to see the jobs that are being run.

workflows:
  version: 2
  # expected: run only on untagged commits, actual: runs on every commit causing double builds
  untagged_build:
    jobs:
      - build:          
          filters:
            tags:
              ignore: /.*/
  # expected: run only on tagged commits. this works except that 'untagged_build' runs too
  tagged_build:
    jobs:
      - build:
          filters:
            branches:
              ignore: /.*/
            tags:
              only: 
                - /^v[0-9]++.[0-9]++.[0-9]++$/
      - deploy:
          requires:
            - build
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /^v[0-9]++.[0-9]++.[0-9]++$/

Single workflow example, untagged commits just do a ‘build’ job, tagged commits run ‘build’ twice and then deploy:

workflows:
  version: 2
  build_deploy:
    jobs:
      - build:
          filters:
            tags:
              only: 
                - /^v[0-9]++.[0-9]++.[0-9]++$/
      - deploy:
          requires:
            - build
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /^v[0-9]++.[0-9]++.[0-9]++$/

Finally, the documented example (https://circleci.com/docs/2.0/workflows/#git-tag-job-execution) simply does not work as described:

workflows:
  version: 2
  un-tagged-build:
    jobs:
      - build:
          filters:
            tags:
              ignore: /^v.*/
  tagged-build:
    jobs:
      - build:
          filters:
            branches:
              ignore: /.*/
	        tags:
	           only: /^v.*/

For untagged commits this will run build. For tagged commits it runs both workflows ‘un-tagged-build’ and ‘tagged-build’.

I think my use case is common, I want to build my code on every commit and only when the commit has a tag do I want to build and deploy.

Finally, I use github for my code repositories and I commit code with git push and if there is a tag I do git tag -a vx.x.x -m "msg" && git push origin vx.x.x && git push. If I add ‘[no build]’ to the commit message it will work as expected but this is not mentioned in the documentation. I would be interested what commands are used in your tests.

Once again, any help is appreciated and if someone from circleci could acknowledge if the feature is actually working or if there is a known bug it would be greatly appreciated, there are a lot of unresolved questions concerning tagging and builds over the last year on these forums.


#12

This is not an option for project collaborators.

I am trying to recreate the workflow that we have at my workplace. Of course everyone has write access to the repository, but nobody can push directly to master. Instead PRs are submitted. As far as I’m aware this is an incredibly typical git workflow. What I would expect to see is:

  • PR is created from a feature branch to master (the PR could equally have been created from a fork, it shouldn’t matter, it’s the PR that should trigger this)
  • Full test suite is run in CI against the PR. The PR is blocked until checks have passed. Possibly could trigger a website deployment to a UAT environment for reviewers.
  • A tag should only trigger a production deployment (or in my case, an npm publish) if it is against a commit that is merged to master. Being merged to master is the “gold standard” for enabling a deployment.

Quite amazed that this setup isn’t directly supported by the filters, I thought (and am convinced from reading the comments of others here) that this is an incredibly standard flow.


#13

You can check if a tagged commit is also in a branch with the command git branch --contains.

In this scenario, you can check if master is in the list.


Deploy on Tag / Branch combination
#14

If there any way to cancel jobs partway through? Without it showing as a failure? In this case I could have a job that simply runs this check and bails if it’s not on master.


#15

Not that I know of no. You’d have to return a non-zero exit code which will fail the build.


#16

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