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:
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.