Repository triggers are used to trigger a configuration when a change is committed to a certain repository.
Repository Trigger Options
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.
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.
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:
- Latest: This will only link the latest changeset to the build.
- All since last successful build: This will add all the changesets that have occurred in other repositories to the current build.
For example, let say my configuration is linked to a repository called myRepository 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 myRepository:
- Fixed annoying deadlock bug. issue #3199.
- Minor UI fixes
- fixed show stopper bug #544
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 myTriggeredRepo which has a repository trigger that will execute a build every time a checkin is made to myTriggeredRepo.
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 myTriggeredRepo. Once the build has finished running, if I check the latest changes made in myRepository, I will see the following checkins:
- Latest: Fixed annoying deadlock bug. issue #3199.
- All since last successful build: Fixed annoying deadlock bug. issue #3199, Minor UI fixes, fixed show stopper bug #544.
Branch Aware Version Control System Options
The options for a Repository Trigger differ slightly depending on the type of repository. If it's a Branch Aware respository (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:
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.
Pattern matched branch
When this option is selected, the trigger will start a build when a change is made to a branch whose 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