...
Repository Trigger Options
...
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 triggeredThe 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 specified in minutes, 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 repositories since the last successful build.
For example, let say Lets assume my configuration is linked to a repository called called myNonTriggeringRepository and 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:
- Fixed annoying deadlock bug. issue #3199.
- Minor UI fixes
- fixed show stopper bug #544
...
On my configuration I have a second repository called myTriggeringRepo which myTriggeringRepo which has a repository trigger that will execute a build every time a checkin is made to myTriggeringRepo.
What I have selected for for Associate Changesets will 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 in myNonTriggeringRepository, I will see the following checkins:
- 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 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
Trigger Branch (for branch-aware repositories)
For branch-aware repositories, this option allows you to further refine the branches to observe as part of this trigger. The options here are: 'All branches', 'Default branch' (as specified within the repository options page), and '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 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 repositorywithin the Repository Options.
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 to users who triggered the build.
The regular expression entered in the screen shot above is ^fis ^feature-.*. This will match any branch in your repository that starts with f-.with feature-.
Trigger Tags (for tag-aware repositories)
| Info |
|---|
Note triggering on tags is only available as from version 1.5 |
Trigger On Tag Changes
Determines how to treat tag changes. Options here include: 'Dont trigger on tag changes',' For all Tags', 'For tags matching pattern'.
Dont Trigger on Tag Changes
Do not trigger when a tag change is detected.
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.
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.
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.
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.
.