Can't trigger workflow on git tag push using when condition

Build Environment
1

Hi,

I am doing some testing and working on a release pipeline.
At some point in my pipeline, I want to update my package.json, push it and then trigger a next workflow to actually deploy to prod.
To do so I thought to update my package.json in a first workflow which we can call “A”. At the end, A, will push a tag doing something like:
git tag -a v0.2 -m "my version 0.2" && git push origin v0.2

I would be then expecting it to trigger a next workflow which would take care of the release.
I am aiming to le the workflow trigger on tag push with a syntax like that

on_tag:
    when: << pipeline.git.tag >>
    jobs:
      - build

Using the when conditional on it. But it does not trigger.

Just for testing, I also tried something like

    when: 
      and:
        - equal: [ v0.3, << pipeline.git.tag >> ]
    jobs:
      - build

using equal; but still.

Using a filter, like:

only_on_push_tag: &only_on_push_tag
  filters:
    tags:
      only: /^v0.5.*/
    branches:
      ignore: /.*/

does work.

But I want to stick to the when approach. I can see in the documentation there is some example using the pipeline.tag, even if different.

workflows:
  my-workflow:
    when:
      and:
        - not:
            matches:
              pattern: "^main$"
              value: << pipeline.git.branch >>
        - or:
            - equal: [ canary, << pipeline.git.tag >> ]
            - << pipeline.parameters.deploy-canary >>

So to conclude, any suggestion on how to trigger a workflow on tag push using the when condition? why is not working? Thanks
For now we are not using any package for bumping the package.json, etc.

1 Like
2

+1

In my case I’m restricted to using workflow conditionals due to the requirements for path-filtering. Filters on jobs do not work in this case as path-filtering requires only a single workflow to be triggered.

Sadly I am also struggling to get the matches or equal logical operator working against the pipeline.git.tag despite following examples & testing:

# staging
  cicd-staging:
    when:
      matches: { pattern: '^v1.0.0-.+$', value: << pipeline.git.tag >> }
    jobs:
      - path-filtering/filter:
          name: 'serverless-cicd'
          base-revision: master
          mapping: |
            dir1/.* dir1-modified true
            dir2/.* dir2-modified true
          config-path: .circleci/serverless-cicd.yml
1 Like
3

We are also seeing this and want to know the answer.

4

I think the issue comes from the fact that <<pipeline.git.tag>> seems to only be populated with a tag value if a job filter exists that first passes all branches and contains a check against possible tag values.

So it seems that a workflow needs the following filter block in place (depending on your config needs)

    filters:
      tags:
         ignore: //
      branches:
         ignore: /.*/

It also seems to mean that a when: structure at the workflow level can not do a check against <<pipeline.git.tag>> as it seems to control the execution of the filter, which in turn is responsible for the population of <<pipeline.git.tag>>

5

Hey all,

what’s happening here is that when for workflows is something that has been added fairly recently. CircleCI has always ignored tag pushes by default, unless opted in via filters as described by @rit1010 or described here.

In effect what’s happening is that without filters we don’t run a workflow and don’t actually make it to the stage where we evaluate when. The best workaround I can offer for now is something along the lines of

filters:
  tags:
    only:
      - /.*/

combined with the when expression of your choice.

In the long run I’m hoping we can collapse these two filtering mechanisms into one, but with the need to preserve backwards compatibility for existing configs that’s easier said than done.

6

Would not more use of the ‘version:’ feature resolve the backwards compatibility issue?

It does seem that there is quite a list of requested improvements to the scripting language that will break what is already developed unless ‘version:’ starts to be used.

7

That’s a fair point, and we’re currently actively looking at the next version of config, which will likely be a smaller, iterative improvement rather than a big change, and is likely to include a fix for this.