How to trigger a build for changes in a subtree

For background, we're using teamcity, git, and github for development.

In our repo, let's say we have 3 subprojects, each in a subdirectory.

  • in subdir A is product A's code
  • in subdir B is product B's code
  • in subdir C is common code shared between them.


We have 2 teamcity configurations to trigger for pull requests:
  • config "prA" builds subdir A and C, and runs only tests in those subdirectories
  • config "prB" builds subdir B and C, and runs only tests in those subdirectories.


What I would like to happen when a pull request is submitted:

  • if changes that are part of the pull request's branch modify code in subdir A or C, run prA
  • if changes that are part of the pull request's branch modify code in subdir B or C, run prB

that way, if a pull request makes changes only in subdir A, only prA will run, and similarly for subdir B/prB. Both will be run if code in subdir C is modified, or if code in both subdir A and B is modified.

After reading the docs, I thought I could do this by adding VCS trigger rules to prA and prB, e.g. for prA:

+:.

-:B/**

However, this doesn't work as I expected. Even if only changes to A were made on a feature branch, sometimes unrelated changes to B or C show up on the 'changes' tab for the build. It looks like changes to the default branch (in our case, "develop") that were pushed between when the feature branch was created and when the pull request is submitted are also considered when calculating whether to trigger. Is there a way to change that behavior?

I tried adding checkout rules to avoid checking out subdir B in a prA build and vice versa, but that didn't work because:

  • agents can't handle git checkout rules, so I had to move checkout to the server
  • our build uses information from git, which isn't available when checkout happens on the server.



Any suggestions?





4 comments
Comment actions Permalink

Hi Andy,

If you do not set up checkout rules, then changes are displayed and included in builds. VCS trigger rules is used to filter out some changes and not to trigger a build for these changes.
If you want changes not to be displayed in the TeamCity UI you should use checkout rules. For git VCS checkout rules works only in case of the server-side checkout.
"our build uses information from git, which isn't available when checkout happens on the server" - could you please provide an example of used information?
The workaround is to split repository to two separate repositories for each project.

0
Comment actions Permalink

During our build we create a file containing a number of git-derived properties; branch name, commiter's email address, commit id, commit message, tags, etc., and include that file in our build. If we run checkout on the server we can't do that.

It sounds like triggering only on changes to the feature branch is something that Teamcity just can't do; it always includes changes made on the default branch as well.  Is that correct?

0
Comment actions Permalink

>It sounds like triggering only on changes to the feature branch is something that Teamcity just can't do; it always includes changes made on the default branch as well.  Is that correct?
If you want build configuration to monitor changes only on feature branch, you can configure branch specification for this build configuration.

When you attach VCS root to the build configuration it starts to monitor all changes in this VCS (if no checkout rules and branch specification are specified). When the build is triggered by VCS trigger all pending changes are included into this build. VCS trigger just defines whether to start the build or not.

0
Comment actions Permalink

My apologies, I wrote "feature branch" when what I meant was "pull request for merging a feature branch"

The thing I am stumbling over is that trigger rules allow you to filter in or out changes in subtrees, but there's no description anywhere (at least, not that I have found) of where the base point is for determining if a file has changed.

So let's say I have a teamcity configuration for a branch specification of "+:refs/pull/(*)/head" (i.e. pull requests), a trigger of "+:foo", and only ever a single file "bar" in the "foo" directory. When a pull request is submitted, presumably Teamcity needs to compare the version of the "foo" file on the tip of the pull request branch to some other revision of the "foo" file in order to see if the file has changed and hence the configuration should be run.  What is the other revision it is compared against?

Minor edit for clarity, by: Andy L

0

Please sign in to leave a comment.