How to ensure suitable builds are not triggered from Git commits to unrelated directories.


I'm working with a Git repo that contains several modules.  I only want a triggered build's dependencies to be rerun if there were changes in the specified module's directory, but not when changes were made in another module's directory.

It's easy to focus the build trigger on a specific directory, even in Git.  However, keeping one of its dependencies suitable when its focus is just a subset of it's dependent's trigger(s) is more complex.

Keep in mind that with Git, a job cannot check out merely a subdirectory of the repository.  It must check out the entire thing.  Since build configurations are linked to what they check out, I can only find out how to limit the dependent job's trigger based on a specific subdirectory. I don't see how its dependencies can also be linked to to those subdirectories alone, thus remaining suitable if their subdirectories remain unchanged. 

For example, say I've got the following directory structure....

-root (Repo 1)

* Project1

** pom.xml

** code

*** code files

* Project2

** pom.xml

** code

*** code files


...and the following build pipeline...

Compile <- Build <- Deploy <- Release

Release's trigger keys off of the Project1 directory, but Compile only needs to be declared unsuitable if change occur within the code directory.  Now say a change was made to just the pom.xml, thus triggering the Release Job.  I only need the Build job and its dependents to rerun.  (As a side note, I also have to have the pom.xml for Compile to run; just not to rerun it if changed.)  How do I tell TC to consider Compile suitable and Build not suitable for the Release jobs rerun pipeline?

As an extention to the example above, suppose the Release job also has a second VCS trigger linked to the following repo:

-root (Repo 2)


Let's also say that only the Deploy job is also attached to Repo 2.  Now suppose changes are made under Repo 1 - Project2.  Release's first trigger does not fire, since it is only keying off of Repo 1 - Project1.  But then something changes in Repo 2 that catches Release's second trigger.  This time, no changes were made even under the first trigger, but changes were made inside Repo 1.  How do we keep the Compile and Build jobs from being considered unsuitable?

Thank you.


Hello John,

As you do not need to run the build chain on the same sources snapshot, then it seems that you do not need to use snapshot dependencies in this case. Instead you can configure only artifact dependency from Deploy to Build build configuration and e.g. download artifact from the last successful build.

Will it work for you?



Thank you for your answer.  This is an interesting solution.  Let me go down that train of thought to make sure I understand all of the ramifications.

If I change the snapshot dependencies from the Deploy to Build and and Build to Compile build configurations to be merely artifact dependencies, it seems I would then need to create 2 new triggers on Build and Compile for changes made to Repo1 - Project1/code and Repo1 - Project1, respectively.  That way, if a change made to Repo1 - Project1/code is made, it will kick off Compile, but if only a change is made to Repo1 - Project1/pom.xml, only Build will kick off.  So that leaves me with at least a couple of questions:

1) Does the creation of a new artifact created by a Compile job automatically trigger a new Build job merely through an artifact dependency?

2) If so, what is to keep Build from kicking off twice; once for the change under Repo1 - Project1 and once for the new artifact created by Compile?

2b) If not, it would seem that the triggers in the Release build configuration would have to remain, but then how would you ensure that it recognizes that its artifact dependencies are stale before it kicks off?

Thank you.


Hi John,

The creation of new artifact does not trigger a new build. You can configure the following triggers:

  • Compile - VCS trigger
  • Build, Deploy, Release - Finish build triggers. 

So Build will start only when Compile finishes.


But what about the case when I only want Build and its downstream jobs to run, because the change was made under Repo1 - Project but not under Repo1 - Project1/code, or when I just want Deploy to run, because only a change in Repo2 was made?  How do I trigger Build and Deploy while keeping Compile and Build from running in those respective instances.

I could add a trigger to Build for changes to Repo1 - Project1, but can I keep that from triggering when the change made under Repo1 - Project1 is under the code directory?  If the build triggers from a change to Repo1 - Project1/code, then I've got 2 Build jobs running (and all of the downstream builds it triggers); one from it's own trigger, and one from the Compile job's completion trigger.


I've got an idea: Exclusion VCS Trigger Rules.  To get the Build trigger to file from a change made to Repo1 - Project1 but not from a change to Repo1 - Project1/code, I can add 2 rules to its VCS Trigger:


That should allow the changes to Project1/code to only trigger a Build job through the Compile completion trigger.


Please sign in to leave a comment.