Teamcity: Build Version Control System Configuration

VCs (Version Control System) is a system used to track version changes of project source files. It also has other names, such as SCM (source code management ). Currently, teamcity supports the following built-in VCs: git, subversion, mercurial, perforce, Team Foundation server, CVS, starteam, clearcase, sourcegear vault, and visual sourcesafe.

This article describes how to set the version control system in build through examples.

VCs Root

A VCs root defines a connection to the version control system. This connection contains all the information (source file path, user name, password, and other settings) for communication between teamcity and the version control system ). With this information, teamcity can monitor code changes and obtain the code locally during build. The VCs root you created must belong to a project and can be used by the build in this project and its sub-projects.

Create VCs Root

You can click the "Attach VCs root" button to start creating the VCs root:

Select your VCs type and click "CREATE:

VCs type

Teamcity provides built-in support for mainstream VCs:

You can select the type of VCs you are using and follow the prompts to create the VCs root. Next, I will illustrate some details through an example. For the type of VCs, select the TFS used by the author (good soil, it is useless to use git !).

VCs root name

The VCs root name must be unique to distinguish different VCs root names. When referencing VCs root, we use this unique name:

VCs root ID

The VCs root ID must also be unique. It will be referenced by internal programs in teamcity and can also be used as a parameter for rest APIs. Generally, you do not need to manually specify it. teamcity will automatically generate it according to the following rules:
Project name + underline + VCs root name.

VCs URL

Point to the VCs URL and enter the address of your code, for example:

Code path

Specify the path for getting code from the code library:

Username and password

The authentication information provided when the code is obtained from the code base:

Forcibly retrieve all files

This is an option related to TFs. This option works when teamcity obtains code through Build agent. When "enforce overwrite all files" is selected, teamcity requests TFs to update all files. Generally, you do not need to do this. Of course, sometimes you may suspect that teamcity has not obtained code from TFS, then you can use this option:

Minimum Check Interval

This option specifies how long teamcity checks for changes to the VCs library. By default, values are inherited from the system. There are system-level settings on the Administration | global settings page. If you want to customize this value, you can select Custom to set it.

Project

Here you can specify the project to which the created VCs root belongs:

Check connection status

You can check whether the current configuration can be correctly connected to VCs before the creation is complete, and click "test connection" to test:

The connection is successful:

Click "CREATE" to create the VCs root.

Configure VCs root checkout rules

We can specify appropriate rules for VCs root to control the paths of the obtained code During build. VCs checkout Rules allows us to get some code in the library and map it to the specified directory on build agent.

For detailed syntax, see the artifact paths section in teamcity: Build basic configuration.

VCs checkout Mode

VCs checkout mode is used to specify how source code files arrive at build agent. From version 10, teamcity supports four types of VCs checkout mode:

Prefer to checkout files on Agent

This method is newly added and recommended by default. The method of getting the code is to first request the code from the build agent to the version library. If not, try again from teamcity server.

Always checkout files on server

Always try to request the version library from teamcity server and then send the code to build agent.

Always checkout files on Agent

Always try to request code from the build agent to the version library. The advantage of this method is that the build agent has a complete workspace, and you can call the version library command during the build process.

Do not check out files automatically

In this mode, the Code is not obtained from the version library before the build is executed. It is mainly used for debugging. For example, you can modify the file in the build directory, and then start a build to verify your change.

Checkout directory

By default, the working directory of build on build agent is controlled by teamcity. However, you can control the build working directory by setting the checkout directory entry to custom path:

In my opinion, the default options of teamcity are quite good. Do not specify this option unless necessary.

Clean build

If you need to clear the build working directory before each build, you can set the clean build option to achieve the goal:

Display options

Allows you to display changes from snapshot dependencies:

Summary

In build, the importance of version control system configuration does not need to be repeated. Fortunately, teamcity provides flexible and diverse configuration methods, allowing us to easily and conveniently implement various use cases.

Teamcity: Build Version Control System Configuration