Git: teamcity.vcsTrigger.runBuildInNewEmptyBranch Property, VCS Checkout Rules and Pull Requests Build Feature don't play well together?
We've been enjoying the ability to build pull requests using the Pull Requests Build Feature. Our configurations have VCS Checkout Rules configured, so only changes to the appropriate parts of our mono repository trigger a build of any given configuration (project) when a PR is created. This also obviously applies to commits to our develop and master branches (ie the only builds triggered are ones affected by the changes committed).
We would now like to trigger builds on new branches created (eg for a QA build we'd like to run all of our configurations as soon as the QA branch off of 'develop' is pushed to the repository).
Nothing is triggered by default when a branch is created, but we found that the teamcity.vcsTrigger.runBuildInNewEmptyBranch property is the way to get such "empty" commits to trigger builds.
Unfortunately, when we enable this parameter, it seems to have the effect of ignoring any of our configured VCS Checkout Rules. Every build configuration is triggered for every pull request, regardless of whether or not those changes affect the component represented by the build configuration.
Is there something else we can do to get our desired effect of _only_ building everything if and only if a whole new branch is created, and otherwise honour the VCS Checkout Rules?
Please sign in to leave a comment.
Hi Wayne,
I'm happy to hear you're having success with the Pull Request Build Feature and that you were also able to figure out how to use the teamcity.vcsTrigger.runBuildInNewEmptyBranch property.
In order to limit the sections of your repository that trigger a build, you can add an entry to the Branch Filter such as
-:feature-*. This will tell the Build Configuration to ignore new branches that start with "feature-".For future reference, we have a lot of detailed information regarding the use of Branch Filters in our documentation. https://www.jetbrains.com/help/teamcity/branch-filter.html#branch-filter.md
The problem is not that unwanted branches trigger builds - it's that the VCS Checkout Rules and Trigger rules are no longer being honored for PR builds that _are_ triggered (ie ANY PR triggers ALL builds that have runBuildInNewEmptyBranch set to true, not just the builds that have PR changes limited to their VCS Checkout/Trigger rules).
Hope that makes sense.
Eric,
Here's an example of one of our builds:
[The %source_root% for this build is specified as 'Services\Monitors\Email']
After we enabled runBuildInNewEmptyBranch, a new PR came in which triggered a build for the above config, even though the PR contained only changes outside the folders specified in the Trigger rules:
[Note that there are apparently "No changes" for this build - which I think is a giveaway that the trigger rules didn't match]
Changes tab for this build:
[Note that the single file changed is outside %source_root% for this config]
Log:
Thanks
Wayne,
Thank you for all of the detailed screenshots, this is helpful. I have replicated your settings but not getting the same results as you.
Are you able to share a portion your teamcity-vcs.log? If so, could you produce this failure again and send that portion of the log to me for further analysis? The file can be shared privately by clicking the"Submit a Request" button at the top of the page.
Eric,
I submitted the logs.
Thanks
Hello,
Could you please tell us what branch specification is configured in the VCS root? Is "develop" branch configured as default branch in the VCS root?
Also, is it correct that so called QA branch works like a tag, i.e. it is just moved from time to time along commits in develop branch?
Yes, 'develop' is the default branch for the VCS root, and we have other branch specifications configured as:
+:refs/heads/master
+:refs/heads/QA
QA is a full branch, not a tag. We don't commit directly to QA, but we will periodically merge develop into QA to trigger a full build and deploy to our QA environment.
Could you please tell me what exact version of TeamCity you are using?
TeamCity Professional 2019.1.2 (build 66342)