I have two workflows with opposite filters and both are run when I do a pull request; I would expect only one to run

Build Environment
1

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…

any ideas ?

workflows:
  version: 2

  build_and_deploy_beta:
    jobs:
      - build:
          filters:
            tags:
              ignore: /^release-.*/

      - deploy_beta:
          requires:
            - build
          filters:
            branches:
              only: master
            tags:
              ignore: /^release-.*/

  build_and_release:
    jobs:
      - build:
          filters:
            tags:
              only: /^release-.*/

      - release:
          requires:
            - build
          filters:
            tags:
              only: /^release-.*/
2

I moved this to a new topic as this is a separate issue and the last topic was 24 days old.

I would recheck the defaults for branch and tag filters. By default, branches include everything and tags exclude everything. Both workflows are running because both build jobs in each workflow are suppose to run. Nothing is telling them not to. A PR is just a branch commit like any other commit. Without any ignore filter, the build jobs will run.

1 Like
3

Thanks for splitting the topic.

Thanks makes sense.

I’ve added ignore: /.*/ telling to ignore any tag but it still builds. How can I tell CI to build only on tags matching /^release-.*/ but ignoring anything else ?

  build_and_release:
    jobs:
      - build:
          filters:
            tags:
              only: /^release-.*/
              ignore: /.*/
4

I also just tried numerous variations on configuration based on what is in the docs and also what has been written by various people in various threads.

It basically seems like regardless of what I do, ‘branches’ is the only filter that CircleCI actually bases any decisions on, when both filters are present.

What I want to do: deploy when I push a tagged release to master. That’s all. I don’t want to deploy based on a tag getting pushed to any other branch, but I don’t think it’s possible to configure this. You can either say “deploy from any branch when a tag gets pushed”, or “always deploy whatever gets pushed to master”.

1 Like
5

You’d need to ignore all branches, not tags. Something like this:

workflows:
  version: 2
  build_and_deploy_beta:
    jobs:
      - build
      - deploy_beta:
          requires:
            - build
          filters:
            branches:
              only: master

  build_and_release:
    jobs:
      - build:
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /^release-.*/
      - release:
          requires:
            - build
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /^release-.*/

But you could probably combine that into one Workflow.

6

Thanks @FelicianoTech.

I’m reading the documentation and trying to understand it: Does it mean that filters branches are ORed to filters tags ? https://circleci.com/docs/2.0/configuration-reference/#filters-1 suggests that

Any branches that match ignore will not run the job.

and it also suggests that adding a tags ignore: /.*/ should ignore also pushes with empty tags.

Any tags that match ignore will not run the job.

7

Git branches and tags are two different things. A tag commit doesn’t have a branch and a branch commit doesn’t have a tag. So the filters for both tags and branches in Workflows are completely separate from each other.

That being said, they have different defaults. By default, CircleCI will build all branch commits and by default CircleCI won’t build tag commits. You use filters when you need to change the default behavior.

1 Like
8

thanks.

Just for ref: I’ve just found another thread where it is discussed if it should be OR (as it is now) or AND. Circle 2.0 Workflow Filters Should be logical AND not OR

9

We’ve also run into this problem.

Pushing a tag and a commit at the same time is a very typical git workflow especially for anyone using NPM. When you run “npm version x.x.x” it will commit a change to package.json and create a git tag.

We’d like to setup our Circle config to build on every commit and do a build + npm deploy on every new tag. From my trials and these threads, it seems like there is no way to accomplish this without triggering a double build on the build + npm deploy step.

1 Like
10

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