Specifying subfolder filter for pending changes
Having just converted a lot (hundreds) of build configurations over to use Git instead of Subversion, I've hit an issue with how pending changes are managed / used by TeamCity. Before explaining the problem though, I need to explain the scenario to add context...
This is a very large legacy monolith codebase with a lot of projects and complicated dependencies. When using SVN, all of the build configs had a VCS root and overrode the 'checkout directory' to point to a particular subdirectory. All build configs checked out to the same _base_ folder though, eg...
Build Config 1's checkout path: C:\Code\TheMonolith\Project1\
Build Config 2's checkout path: C:\Code\TheMonolith\Project2\
The TeamCity build config dependencies are key, as some projects expect that other projects have already been built in that folder structure.
This worked okay for SVN.
Given for Git, it doesn't make sense to have different directories with different HEADs - I've changed all build configs' checkout directories to be the base path - ie. the Git repo root - eg. `C:\Code\TheMonolith\`, and set the "trigger rule" to be what the checkout path used to be when using SVN. This gets us most of the way there.
The problem we're facing now is with snapshot dependencies and 'pending changes'. Because a build config's calculated "changes" are across the entire repo - it means that ALL snapshot dependencies are built for ANY change in Git. Ideally, we want to specify a subfolder that affects the pending changes - like we did with the trigger path.
The only other related setting I can see are the checkout rules. But from what I understand - this seems to be a workaround for Git where it checks out the entire repo, then deletes everything that doesn't match the checkout rule. Which for our scenario definitely isn't what we want.
Feels like I've hit a bit of a deadend with this, and the only hack I can think of to get around this is to add a new build step at the start of each build config, which uses the REST API to check for pending changes, and stop the build (with success status) if there are no pending changes within the trigger rule path. This feels very hacky, and a lot of work to implement across hundreds of build configs.
Does anyone have any ideas/suggestions?
Please sign in to leave a comment.
Hello Dan,
First of all, I am most sorry about the delayed response here.
Checkout rules are indeed the way to go here - apart from affecting the checkout process (which will largely stay the same under the Git, this is correct - we have a feature request on the matter), these will also act as a filter for the pending changes so configurations will only "see" the changes that are "relevant" to them, and snapshot dependencies/build triggers will act accordingly. This way, trigger rules may become optional, too.