Before reading this page, it is highly recommended you read the Triggers page.

Repository triggers are used to trigger a configuration when a change is committed to a certain repository.

Repository Trigger Options

This section describes the Build Completed Trigger options. Visit the Triggers page for information regarding options such as 'Build Priority and 'Force Repository Check', which are shared by all trigger types.

Repository

This is the repository that this trigger will monitor for any new changesets. If a new changeset is detected in this repository then a build will be triggered.

Quiet Period

When a changeset is detected on the selected repository, a build is created and put in the Build Queued state. It sits in the queued state until the quiet period expires. While in the quiet period, additional commits to the repository will not trigger new builds, however these new changesets will be added to the build that is currently in the quiet period. This is useful when you want to group a set of quickly committed changes into one build.

The Quiet Period is specified in minutes.

Associate Changesets

This tells the trigger which changesets it should associate with this build for all other non-triggering repositories. Non-triggering repositories are basically all repositories that are linked to the current configuration excluding the repository that is triggering the build.

There are two options for associate changesets:

For example, let say my configuration is linked to a repository called myNonTriggeringRepository and this repository is not linked to a repository trigger. Since the last time a build was executed successfully, I have made the following checkins to the source code in myNonTriggeringRepository

With these checkins, lets assume that Fixed annoying deadlock bug. issue #3199 is the latest checkin to be made.

On my configuration I have a second repository called myTriggeringRepo which has a repository trigger that will execute a build every time a checkin is made to myTriggeringRepo.

What I have selected for Associate Changesets will change the latest changesets that I will see associated with my builds.

For this example, a build is triggered by a change being detected in myTriggeringRepo. Once the build has finished running, if I check the latest changes made in myNonTriggeringRepository, I will see the following checkins:

Branch Aware Version Control System Options

The options for a Repository Trigger differ slightly depending on the type of the selected repository. If it's a branch aware repository (Mercurial,Git, Subversion, PlasticSCM) you will get additional options such as which branches will trigger a build.

For example, you could setup a repository that monitors all branches. You could then create 3 repository triggers that monitor each key branch (dev branch, release branch and/or feature branches). These different triggers could then write different variables to a triggered build.

The three types of branch monitoring options are:

All Branches

When this option is selected, the trigger will start a build if any changes are made to any branch. You also get the option to only send notifications to users who triggered the build.

Default Branch

When this option is selected, the trigger will start a build if a change was made to the repository's default branch. The default branch is specified when you create a repository.

Pattern matched branch

When this option is selected, the trigger will start a build when a change is made to a branch and that branch's name matches the regular expression you supply. You also get the option to only send notifications to users who triggered the build.

The regular expression entered in the screen shot above is ^f-.*. This will match any branch in your repository that starts with f-