Configuring VCS Settings
A Version Control System (VCS) is a system for tracking the revisions of the project source files. It is also known as SCM (source code management) or a revision control system. The following VCSs are supported by TeamCity out-of-the-box: Git, Subversion, Mercurial, Perforce, Azure DevOps, CVS, StarTeam.
Connection to a version control system is defined by a TeamCity VCS root. A project or a build configuration in TeamCity can have one or more VCS roots attached; a build configuration can also define the workspace for the builds via other checkout options like Checkout Rules.
TeamCity always monitors the repositories from the server-side to detect changes and display them in the UI. Depending on the specified VCS Checkout Mode the actual repository checkout can also happen on the agent-side.
TeamCity performs VCS-related operations per each VCS root separately, thus it is advised to reuse VCS roots with same settings.
When parameter references are used in a VCS root, TeamCity performs VCS-related operations per each "VCS root instance", where "instance" is a unique set of VCS root parameters after references resolution. Adding parameters to the VCS roots does not reduce the number of VCS operations performed, it just allows sharing settings more effectively.
Attach VCS Root
VCS settings are configured on the Version Control Settings page for a project or a build configuration: you can attach an existing VCS root to your project/build configuration, or create a new one to be attached. This is the main part of VCS parameters setup; a VCS root is a description of a version control system where project sources are located. Learn more about VCS Roots and configuration details here.
Configure Checkout Rules
When several VCS roots are attached or you need to check out only a portion of the repository, specify the checkout rules for the VCS root to provide advanced possibilities to control sources checkout. With the rules you can exclude and/or map paths to a different location on the build agent during checkout.
Configuring Checkout Options for Build Configuration
Checkout Settings
Setting | Description |
|---|---|
VCS Сheckout Mode | To define how project sources reach an agent, use the VCS Checkout Mode options. |
Сheckout Directory | The Build Checkout Directory is a directory on the TeamCity agent machine where all sources of all builds are checked out into. |
Clean build | Define whether you want to clean all files in the checkout directory before the build. See Clean Checkout for details. |
Changes Calculation Settings
Setting | Description |
|---|---|
Show changes from snapshot dependencies | Configure whether TeamCity will show changes from snapshot dependencies. This also affects treatment of pending changes in schedule trigger. |
Exclude default branch changes from other branches | By default, when displaying pending changes in a feature branch or changes of a build on a branch, TeamCity includes changes in the default branch (till a build in the default branch) as well. This allows tracking the cases when a commit that broke a build was fixed in the default branch, but not in a feature branch. However, for large projects with multiple teams simultaneously working on lots of different branches this means that all the project committers (regardless of the branch they are committing to) will be notified when, for example, a commit in the default branch broke the build or if a force push was performed. If you want to see the changes in a feature branch only, check the box to exclude changes in the default branch from being displayed in other branches. |
Branch Filter
You can use a branch filter to limit the set of branches available for the build configuration. By default, no limits are applied.
Other VCS-Related Settings
Configure a VCS trigger if you want the build to be started on new changes detection.
Additionally, you can add a label into the version control system for the sources used for a particular build by means of the VCS Labeling build feature.