yes
2.134.2, CentOS 7
VisualStudio.com
I have a yaml definition
trigger:
branches:
include:
- master
exclude:
- tags/*
- refs/tags/*
phases:
- phase: Test
queue:
name: ResSimTesting
demands:
- Agent.OS -equals Linux
steps:
- task: Bash@3
displayName: bash me some
inputs:
targetType: 'inline'
script: |
echo hello
which runs in CI mode by default (ie leaving trigger settings in vsts ui alone). It fails to ignore the tag and try to build it

however if I whitelist master in the UI this doesn't happen

Am I missing something here?
@plang85 can you make it work with a pure designer build definition?
i am trying to figure out whether this is YAML problem or it's a generic limitation for the build system.
If I define the whole thing in the UI and have the branch filter set to master it works as expected (ignores any pushed tags)
@plang85 do you means if your YAML looks like:
trigger:
branches:
include:
- master
it will also trigger on tag?
I hit an exception when attempting to repro this: Expected a Commit, but objectId e0e48f6a41f99e979256f27a9177c791e8dabb9c resolved to a Tag
I'll dig in more later today.
@plang85 when you tried, did you get a similar error that I did? i'm fixing that, but want to confirm whether you are running into a different issue.
Thanks for looking into this. I get the same error, yes. However I would like to exclude any tags to be build, and I was not able to find the right yaml syntax for than.
I'm having the same problem and also tried disabling it in the YAML config to no avail. @ericsciple Has this been identified as a bug or is there something we can set in the YAML?
There were bugs around tags. I checked in fixes which are rolling out with the current deployment. It will take a couple weeks to reach all accounts. The problem was annotated tags were causing failed builds to be created, whether the file excluded tags or not (error occurred while attempting to load the yaml file)
Really appreciate the explanation @ericsciple, thanks!
Closing the issue here. The deployment has reached most accounts, and will roll out to the rest sometime next week.
I have the opposite problem. When I use triggers for tagged commits, they don't get triggered
trigger:
branches:
include:
- refs/heads/master
- refs/tags/*
Having the same issue as above, although I'm not manually defining triggers. Before a few weeks ago, it was defaulting to building on tags just as it was defaulting to building on branch commits.
@domoritz are you using an Azure Repo or GitHub? Are you using lightweight tags or annotated tags? Note, when the tag is pushed, the triggers defined by the yaml file in that commit is what is used to determine whether to trigger a build.
@EzraBrooks there were inconsistencies and bugs with triggers on tags. The expected behavior going forward is, you must list refs/tags/* (or specific tag patterns) if you want tags to trigger.
Thanks for the info, I'll try it out.
I use GitHub with normal git tags. The tank file is in the tagged commit.
With identical configuration to @domoritz, I'm not getting builds on tags either.
@chrisrpatterson from azure helped me in https://github.com/vega/ts-json-schema-generator/issues/49
@ericsciple based on your comment, I believe this document is no longer correct. Can you confirm I'm interpreting it correctly?
If you don't specify any tag triggers, the default is as if you wrote:
trigger:
tags:
include:
- *
The default should be refs/heads/*
If that is not the behavior you are seeing, then please open an issue here
Note, the file is read from whichever branch you push to. So for example, if you push to refs/heads/foo then the trigger specification defined in the file in that branch is used when evalating where to trigger a build.
@solvingj
@solvingj sorry I see now that you are talking about tags specifically. I believe the docs are wrong. I'll follow up with PMs and confirm, and we'll get the docs updated.
I believe everything I said in the previous reply is correct. The default is refs/heads/* and tags are refs/tags/... so they would not match the default.
@vijayma @vtbassmatt can you help confirm the expected default behavior?
I made a copy and paste error in the docs. I agree, the default should be to _not_ build on tags unless you specifically opt in. I'll fix it.
I'm seeing this issue right now. I have a yml build that's getting triggered with a failure on a new tag. I added the exclude block to branch triggers and still get the triggered failures.
@jbeesonnuva can you open a Developer Community ticket with details including the relevant YAML snippet? Thanks.
Most helpful comment
I have the opposite problem. When I use triggers for tagged commits, they don't get triggered