TeamCity 2019.1.2 - VCS Trigger Rules not working - How can I prevent a build from starting by blocking specific directories?
Hello.
I'm trying to setup our builds so that they only trigger if files in our source directory change, not files in our build scripts/tools directory. This seemed pretty straight forward with the use of the VCS Trigger rules, however I have been unable to get them to function. Can you let me know if I'm doing something incorrectly?
For a build configuration, we have one attached VCS Root. The repo is a Subversion repo. The checkout rules for this root are:
+:%system.Platform.VCS.Directory.Build% => %system.Platform.VCS.Directory.Build%
+:%system.Platform.VCS.Trunk%\Tools\DiskTools => .
+:Tools\Deployment\Tools => Dep_Tools
I added the 3rd rule to use for testing this process. What I really want to block is any changes from the folder in the first rule. The variable used in the first rule specifies a single directory named "Build".
I tried adding the following VCS Trigger Rules, but in each case the build would still trigger if there were changes:
-:root=Monaco_Monaco:Build/**
-:root=Monaco_Monaco:%system.Platform.VCS.Directory.Build%/**
-:root=Monaco_Monaco:Build
-:Build
-:Build/**
None of those stopped the build from triggering when changes were made to the 'Build' folder, or it's sub-folders. Can you let me know if I'm using these rules incorrectly? Is there a way to do what I want, which is to sync and use the 'Build' folder for the build but not have any file changes from those folders trigger a build?
Thanks in advance for the help, I appreciate it.
Jim
EDIT: Corrected the last two VCS Trigger rules. I realized I left the "root=" in the rule when I was pasting. "root=" was only included when I was actually using the VCS Root ID.
Please sign in to leave a comment.
Is this an issue where the VCS Trigger rules don't override the VCS Checkout rules? I've tried some more things but no matter how I format the VCS Trigger rule syntax the build always starts.
Jim
Hi Jim,
VCS Trigger rules should match the files after the checkout rules have been applied. If you are moving the set of tools that should be ignored into the "Build" subfolder, then the first rule seems correct, assuming that the folder where you place what you do not want to trigger is within the Build subfolder. If you only have one vcs root, you can (and maybe should) remove the "root=<id>" element from the rules.
There are some more details in here: https://www.jetbrains.com/help/teamcity/configuring-vcs-triggers.html#ConfiguringVCSTriggers-VCSTriggerRules . Your setup looks fine with the first rule, although maybe checking the instructions helps in case you might have missed something.
If I read what you wrote correct, you are saying it first applies the VCS Checkout rules, which includes the 'Build' folder, and then checks the VCS Trigger rules? If that is the case that it seems what I want to do won't work. I've tried both with/without the "root=" and it doesn't make a difference.
I want to sync the 'Build' folder and use the files inside for certain tasks during the build, but I don't want any changes from files in that folder & subfolders to cause a build to run. I just can't figure out how to make that happen.
I'll go through that documentation. I've been reading a lot about it so I believe I've already read that. It *seems* like what I want to do is straight-forward, I just can't get it to work.
Thanks for the help, I appreciate it.
Jim
Would it be possible for somebody internal to JetBrains to set this up and see if it's working as expected?
It's basically one VCS Root (Subversion) with two Checkout rules. It syncs one folder & subfolders from /Build and another from /Trunk. I then setup a VCS Trigger rule to exclude files from 'Build' yet it doesn't seem to work.
Jim
One more question. I think I was able to get this to work. Looking at the VCS Checkout rules above, for rule #3, I added two VCS Trigger rules to see if they would work:
-:Dep_Tools/**
-:Dep_Tools\**
(I'm not sure if the backward/forward slash matters, I tried them both just to see if it would work).
It looks like it did detect the change and added the item to the 'Pending' changes, but did not start the build this time. (I'm not sure why this hasn't been successful with the 'Build' folder, I will have to try that again).
Denis, is that your understanding of how this feature is supposed to work? Is there a way to prevent the item from appearing the in 'Pending' changes? VCS Trigger rules doesn't seem like the right place for something like that. I don't know if that feature exists. This feels like progress though. Thank you Denis.
Jim
Hi Jim,
sorry for the delay. We use checkout rules and vcs trigger rules constantly internally, they're thoroughly tested, which means that in most situations this is just a configuration issue. It's obviously possible that something has slipped through our tests and our own setups, but common scenarios such as yours would be really rare.
About the pending changes, as soon as TeamCity detects that changes exist in a VCS Root, all build configurations that have it attached and not excluded via checkout rules will show it as a pending change, because that's what pending changes are. VCS Triggers will trigger a build when there are pending changes that match the trigger rules. In short, VCS Roots and checkout rules determine what the build will track and where to put it, while the Trigger will exclusively trigger based on the changes detected by the build configuration. I hope this clarifies better how this is supposed to work. In fact, a usual troubleshooting step here is to determine whether the changes are being detected as pending changes or not. If they are, the issue is on the trigger, if they aren't, the issue is at the vcs root (including checkout rules).
About the slash direction, the JVM that runs teamcity is usually smart enough to understand the OS you are running in and adapt to it, I'm not aware of any issues with using the "\" outside of windows, but by default "/" is supported on every OS.
Thanks for the reply Denis, I appreciate it.
I'm at the point where I've configured it so that it DOES NOT trigger a build when the changes happen in that directory, but it does still show the item as a 'Pending' change that would be picked up when the next build is triggered. It sounds like that is correct and the trigger rules are working as intended.
It doesn't sound like there is a way to fully prevent the change from showing up as 'Pending', correct? Ideally there would be a setting outside of the VCS Triggers to prevent that, but I haven't found that to be possible. I love TeamCity but not a huge fan at how 'Pending' changes currently work. I wish there was a way to clear or 'refresh' them, but that's another issue entirely.
So, to summarize, adding a trigger rule won't affect the 'Pending' changes at all, but will prevent a build from running if the change matches the trigger rule, which is what I'm now seeing.
Thanks again Denis,
Jim
Hi Jim,
Yes, all of that seems correct. We have a request to hide pending changes from the UI here: https://youtrack.jetbrains.com/issue/TW-15746, please watch and vote for it, and feel free to add any comment you consider appropriate.
As of now, hiding potentially useful information is not a priority, but there is a set of reasonable scenarios where this could be set up, so more votes will help our devs get it implemented.
Thanks. I like 'Pending' as well, until it's wrong. We just work with building specific tags/branches quite bit so the 'Pending' and change list can be quite wrong for many of our builds. I don't want to hide 'Pending' in most cases. What I would really like is the ability to force TeamCity to re-evaluate the change list when appropriate.
Jim