I have a situation that, after reading the TC docs, leaves me wondering what should happen exactly. Of course my test didn't work, so then I'm left wondering where exactly my problem is.

Here's what I'm trying to do. I want a relatively simple VCS trigger so that if anything changes I get a build unless the committer happens to be a user named "teamcity". So my rules look like:

+:.-:user=teamcity;:.

The docs for the VCS triggers state:

For each file in a change the most specific rule is found (the rule matching the longest file path). The build is triggered if there is at least one file with a matching "include" rule or a file with no matching rules.In this case however, it would seem that both rules are going to have equal path lengths, so which one wins? My test showed that the first rule won because I got a build resulting from a commit made by the "teamcity" user. I assume the rules are concerned with the VCS user and that those have nothing to do with TC users, in this context but that could be a bit more explicit in the documtation.

Votes

0

Share

The quote from documentation that you mentioned refers to the file paths only. VCS root, username and comment are treated as separate additional criteria. For each file the most specific rule will apply if the file is included. (We will review our doc to make it clearer).So for the provided example builds should not trigger if commit is done by user "teamcity".You should use VCS username in VCS trigger rules as specified in the documentation "VCS_username - if specified, limits the rule only to the changes made by a user with the corresponding VCS username".

I would have thought my example would have worked as needed, but in fact it did not. Since in my mind the file paths to be considered would be of equal length for the two rules I was left wondering what does TeamCity use next to break the tie? Are inclusions favored over exclusions or vice-versa? Or is it the ordering of the rules? Emperical testing indicates the ordering of the rules has no affect because I swapped their order and the commit by the "teamcity" user still caused a trigger.

Hopefully the above confusion helps you see where the documentation might be clariified. Also, if TeamCity records somewhere what file/rule triggered a build (or prevented one), it would be excellent if that were more visible. (I'm unaware of any such indication though.)

I believe I've found a working solution to my problem, but it's only had limited testing thus far. The type of commit for which I don't want a build triggered is made by running "tito tag" [https://github.com/dgoodwin/tito] -- I'm primarily using TeamCity to build RPM packages which primarily contain Python code so the actual building is really more a job of packaging. So in my context, a build step has user teamcity running "tito tag" and then "git push". Thus my rules now look like:

+:.-:refs/tags/*-:rel-eng/packages/*

So while this (apparently) works, it's less flexible than if I could simply exclude all commits by user "teamcity".