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

Repository Trigger Options

Image RemovedImage Added

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.The repository related to this trigger (these are presented on the 'Repositories' tab).

Quiet Period

When a changeset is detected on the selected repository, a build is created and put in the the Build Queued state. It sits waits in the a 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 feature is particularly useful when you want to group a set of quickly committed changes into one a single build.

The Quiet Period is can be specified in minutes or seconds and defaults to 5 minutes.

Associate Changesets

This tells the trigger which changesets it should associate Identifies which Changesets should be associated with this build (relevant 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, that did not activate this triggering.

There are two options for associate changesetsChangesets:

• Latest: This will only link the latest changeset Changeset to the build.
• All since last successful build: This will add all the changesets that have occurred in other all repositories to since the current last successful build.

For example, let say Lets assume my configuration is linked to a repository called myRepository and 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 myRepositorycheck-ins: 

• Fixed annoying deadlock bug. issue #3199.
• Minor UI fixes
• fixed show stopper bug #544

With these checkinscheck-ins, lets assume that Fixed annoying deadlock bug. issue #3199 is the latest checkin check-in to be made.

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

What I have selected for associate changesets will 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 myTriggeredRepomyTriggeringRepo. Once the build has finished running, if I check the latest changes made in myRepositoryin myNonTriggeringRepository, I will see the following checkinscheck-ins:

• With Associate Changesets set to 'Latest':  Fixed annoying deadlock bug. issue #3199.
• With Associate Changesets set to '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:

All Branches

...

Only notify users who caused the build

Tick this to restrict any notifications, due to subscriptions on builds started by this trigger, only to the users who committed changes to the triggering repository which are associated with the build.

Branch (for branch-aware repositories)

Image Added

Trigger On

For branch-aware repositories, this option allows you to further refine the branches to observe as part of this trigger. The options available are:

• All branches
• Default branch (as specified within the repository options page)
• Pattern matched branches

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

Image Removed

Image Added

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 createcreate a repository a repository.within the Repository Options.

Image Added

Pattern matched branch

Image Removed

When this option is selected, the trigger will start a build when a change is made to a branch whose name matches and the full branch path 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 ^fbelow is ^feature-.*. This will match any branch in your repository that starts with f-. a Git or Mercurial repository that starts with feature-. 

Image Added

Note that the regular expression matches against the full branch path which depends on the repository type as follows:

Git and Mercurial:              branchname
TFS and Plastic SCM:         /branchname
Subversion:                        /branches/branchfolder/

So the pattern in the above example would be ^/feature-.* for TFS and Plastic SCM and ^/branches/feature-.* for Subversion.

Skip commits previously built for this configuration

Commits which have already been built on one branch may appear on a new branch after a merge. This option can be used to prevent this trigger starting a duplicate build for a commit previously built as a result of any trigger or manual build on this configuration.

Skip commits previously built by this trigger

Visible only if the 'Skip commits previously built for this configuration' checkbox is not ticked.

Commits which have already been built on one branch may appear on a new branch after a merge. This option can be used to prevent this trigger starting more than one build for the same commit.

Tags (for tag-aware repositories)

Image Added

Trigger On

Determines how to treat tag changes.  Options here include:

• Don't trigger on tag changes
• Tag changes for all tags
• Tag changes for tags matching pattern.

Don't trigger on tag changes

Do not trigger when a tag change is detected.

Tag changes for all tags

When this option is selected, a page of additional options will appear. If at least one of the conditions is met, a build will be initiated. Please note the tag detection must also be enabled in the settings for the selected repository.

Image Added

Trigger on new tags

When a new tag is detected, a new build will be triggered .

Trigger on tag deletions

When a tag is deleted, a new build will be triggered.

Trigger on tag movements 

When a tag is moved from one changeset to another, a new build will be triggered.

Include Tag changes made by ContinuaCI 

Tags can be manipulated by the Continua system itself (for example by an Event Handler).  If tag changes of this nature should trigger a build, select this option.  Please note that the options above (eg trigger on new tags) will be taken into account.  For example if the 'Trigger on new tags' option was selected as well as the 'Trigger on tag changes made by Continua CI', then new tags made by the Continua system user will trigger a build.  Tag changes made by the Continua user are ignored by default.

Only Trigger on tag Changes

Ignore changesets which are not the result of a tag change.

Tag changes for tags matching pattern

When this option is selected, a page of additional options will appear. If at least one of the conditions is met, a build will be initiated. Please note the tag detection must also be enabled in the settings for the selected repository. 

Image Added

Tag Pattern

A regular expression pattern defining which tags to consider

Trigger on new tags

When a new tag is detected, a new build will be triggered .

Trigger on tag deletions

When a tag is deleted, a new build will be triggered.

Trigger on tag movements 

When a tag is moved from one changeset to another, a new build will be triggered.

Include Tag changes made by ContinuaCI 

Tags can be manipulated by the Continua system itself (for example by an Event Handler).  If tag changes of this nature should trigger a build, select this option.  Please note that the options above (eg trigger on new tags) will be taken into account.  For example if the 'Trigger on new tags' option was selected as well as the 'Trigger on tag changes made by Continua CI', then new tags made by the Continua system user will trigger a build.  Tag changes made by the Continua user are ignored by default.

Only Trigger on tag Changes

Ignore changesets which are not the result of a tag change.

File Filters (for repositories which list files)

Image Added

Only trigger when files or folders are changed

Tick this checkbox to ignore changesets which do not include file or folder changes. Depending on the repository type, this will exclude changesets which are due only to property changes, tagging or branching. Note that some repository types only record file not folder changes. 

When this checkbox is ticked additional options will be revealed.

Image Added

File or Folder Change Types

Use these checkboxes to restrict the types of file or folder change which will trigger a build. A changeset must include at least one file or folder change of one of these types to trigger a build

File or Folder Patterns

You can use Include and Exclude patterns to further restrict the changesets which trigger a build to those containing (or not containing) changes to certain files or folders.

Note: Exclude patterns override include patterns. 

Include

One regular expression per line. A changeset must contain at least one file (or folder) change with a path which which matches any of the specified regular expressions to trigger a build. 

Exclude

One regular expression per line. The behaviour of exclude patterns depends on the value selected for the Exclude Where dropdown list as follows:

All files or folders match exclude patterns: A changeset will not trigger a build if the paths of ALL file changes match any of the specified regular expressions. 

Any files or folders match exclude patterns: A changeset will not trigger a build if the path of ANY of the file (or folder) changes matches any of the specified regular expressions. 

Ignore case when matching file and folders

Tick this if to match file and folder paths independent of the character case

Comment Filters

Image Added

Comment Patterns

You can use Include and Exclude patterns to further restrict the changesets which trigger a build to those containing (or not containing) specified comments. Note that exclude patterns override include patterns. 

Include

A changeset comment must match the specified regular expression to trigger a build. 

Exclude

A changeset will not trigger a build if its comment matches the specified regular expression. 

Ignore case when matching comment

Tick this if to match comments independent of the character case