Team Services | TFS 2015 | Previous versions (XAML builds)
On the Triggers tab you specify the events that will trigger the build. You can use the same build definition for both CI and scheduled builds.
Continuous integration (CI)
Select this trigger if you want the build to run whenever someone checks in code.
Note: This trigger is not available if you've selected External Git as your repository.
Select this check box if you have a lot of team members uploading changes often and you want to reduce the number of builds you are running. If you select this option, when a build is running, the system waits until the build is completed and then queues another build of all changes that have not yet been built.
If you are using batched changes, you can also specify a maximum number of concurrent builds per branch.
If your repository is Git then you can specify the branches where you want to trigger builds. You can use wildcard characters.
Path filters in Team Services and TFS
If your Git repo is in Team Services or TFS, you can also specify path filters to reduce the set of files that you want to trigger a build.
- If you don't set path filters, then the root folder of the repo is implicitly included by default.
- When you add an explicit path filter, the implicit include of the root folder is removed. So make sure to explicitly include all folders that your build needs.
- If you exclude a path, you cannot also include it unless you qualify it to a deeper folder. For example if you exclude /tools then you could include /tools/trigger-runs-on-these
- The order of path filters doesn't matter.
For example, you want your build to be triggered by changes in master and most, but not all, of your feature branches. You also don't want builds to be triggered by changes to files in the tools folder.
Select the version control paths you want to include and exclude. In most cases, you should make sure that these filters are consistent with your TFVC mappings on the Repository tab.
Subversion polling interval
Select the days and times when you want to run the build.
If your repository is Git, GitHub, or External Git, then you can also specify branches to include and exclude. You can use wildcards.
Example: Nightly build of Git repo in multiple time zones
Example: Nightly build with different frequencies
TFVC gated check-in
If your code is in a Team Foundation version control (TFVC) repo, use gated check-in to protect against breaking changes.
By default Use workspace mappings for filters is selected. Builds are triggered whenever a change is checked in under a path specified in your mappings on the repository tab.
Otherwise, you can clear this check box and specify the paths in the trigger.
How it affects your developers
When a developers try to check-in, they are prompted to build their changes.
The system then creates a shelveset and builds it.
For details on the gated check-in experience, see Check in to a folder that is controlled by a gated check-in build process.
Option to run CI builds
By default, CI builds are not run after the gated check-in process is complete and the changes are checked in.
However, if you do want CI builds to run after a gated check-in, select the Run CI triggers for committed changes checkbox. When you do this, the build process does not add ***NO_CI**\* to the changeset description. As a result, CI builds that are affected by the check-in are run.
A few other things to know
Make sure the folders you include in your trigger are also included in your mappings on the Repository tab.
How do I protect my Git codebase from build breaks?
If your code is in a Git repo on Visual Studio Team Services or Team Foundation Server, you can create a branch policy that runs your build. See Improve code quality with branch policies. This option is not available for GitHub repos.
I had a build scheduled but it build didn't run. What happened?
If your code is in Team Services, then at least one of your users must sign in regularly for scheduled builds to run.
Can I use the CI trigger with an External Git repo?
Can I chain builds so that one build triggers another?
Do I need a build agent?
You need at least one agent to run your build. Get an agent.
I can't select a default agent queue and I can't queue my build. How do I fix this?
See Administer queues.