...
Repository Trigger Options
Repository
The repository related to this trigger (these are presented on the 'Repositories' tab).
...
This feature is particularly useful when you want to group a set of quickly committed changes into a single build.
The Quiet Period is can be specified in minutes , or seconds and defaults to 5 Minutesminutes.
Associate Changesets
Identifies which Changesets should be associated with this build (relevant for all other non-triggering repositories). Non-triggering repositories are all repositories linked to the current configuration, that did not activate this triggering.
...
- 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 all repositories since the last successful build.
For example, Lets assume 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 checkinscheck-ins:
- Fixed 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 myTriggeringRepo which has a repository trigger that will execute a build every time a checkin check-in is made to myTriggeringRepo.
...
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 checkinscheck-ins:
- With Associate Changesets set to 'Latest': Fixed deadlock bug. issue #3199.
- With Associate Changesets set to 'All since last successful build': Fixed deadlock bug. issue #3199, Minor UI fixes, fixed show stopper bug #544.
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 You also get the option to only send notifications to users who triggered the build.
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 The options here 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
...
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 within the Repository Options, can be overridden in the Configuration Repository Branch Mappings or the trigger Branch Mappings .
Pattern matched branch
When this option is selected, the trigger will start a build when a change is made to a branch and the full branch path matches the regular expression you supply.
...
Trigger Tags (for tag-aware repositories)
| Info |
|---|
Note triggering on tags is only available as from version 1.5 |
...
Trigger On
Determines how to treat tag changes. Options here include: '
- Dont trigger on tag changes
...
- Tag changes for all tags
- Tag changes for tags matching pattern
...
- .
Dont
...
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.
Trigger on new tags
...
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.
Tag Pattern
A regular expression pattern defining which tags to consider
...
Ignore changesets which are not the result of a tag change.
File Filters (for repositories which list files)
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.
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 that 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
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