Git

Fetch URL

The URL of the remote Git repository used for fetching data from the repository.

Push URL

The URL of the target remote Git repository used for pushing annotated tags created via VCS labeling build feature to the remote repository. If blank, the fetch URL is used.

Default branch

Configures default branch. Parameter references are supported here. Default value is refs/heads/master.

Branch specification

Lists the patterns for branch names, required for feature branches support. The matched branches are monitored for changes in addition to the default branch. The syntax is similar to checkout rules: +|-:branch_name, where branch_name is specific to the VCS, i.e. refs/heads/ in Git (with the optional * placeholder).

Use tags as branches

Allows monitoring / checking out git tags as branches making branch specification match tag names as well as branches (for example,+|-:refs/tags/<tag_name>). By default, tags are ignored.

Username style

Defines a way TeamCity reports username for a VCS change. Changing the username style will affect only newly collected changes. Old changes will continue to be stored with the style that was active at the time of collecting changes.

Submodules

Select whether you want to ignore the submodules, or treat them as a part of the source tree. Submodule repositories should either not require authentication or use the same protocol and accept the same authentication as configured in the VCS root.

Username for tags/merge

A custom username used for labeling.

Anonymous

Select this option to clone a repository with anonymous read access.

Password / personal access token

Specify a valid username (if there is no username in the clone URL; the username specified here overrides the username from the URL) and a password to be used to clone the repository.
For the agent-side checkout, it is supported only if Git 1.7.3+ client is installed on the agent. See TW-18711.
For Git hosted from Team Foundation Server 2013, specify NTLM credentials here.

You can use a personal access token instead of a password to authenticate in GitHub, Azure DevOps Services, GitLab, JetBrains Space, and Bitbucket. When connecting to Azure DevOps, remember to set the Code access scope to Code (read) / Code (read and write) for versioned settings in the repositories you are about to access from TeamCity.

When using an existing Bitbucket Cloud, Bitbucket Server, GitLab or Azure DevOps Services connection to create a VCS Root, TeamCity will use a refreshable token instead of the password.

Refreshable token

If a VCS root that fetches data from a GitHub, Bitbucket Server, Bitbucket Cloud, Azure DevOps, or GitLab was configured using a TeamCity connection, refreshable tokens are enabled by default. Such tokens are short-lived providing more security than passwords or personal access tokens: the TeamCity server refreshes them automatically without sharing any related data with agents.

The Token field displays information about the user who obtained the token and the connection that provided the token.

You can specify a username here if there is no username in the clone URL (the username specified here overrides the username from the URL).

For Azure DevOps, Bitbucket Server, Bitbucket Cloud, and GitLab you can click the Acquire new button to instantly reissue the token used by the VCS root with a token issued for the current user.

Private Key

Valid only for SSH protocol. A private key must be in the OpenSSH format.

Select one of the options from the Private Key list and specify a valid username (if there is no username in the clone URL; the username specified here overrides the username from the URL).
Available Private Key options:

• Uploaded Key — select this option to utilize the key(s) uploaded to the project.

• Default Private Key — select this option to utilize the keys available on the file system in the default locations used by common ssh tools: the mapping specified in <USER_HOME>/.ssh/config if the file exists or the private key file <USER_HOME>/.ssh/id_rsa (the files are required to be present on the server and also on the agent if the agent-side checkout is used).

• Custom Private Key — supported only for server-side checkout. Fill the Private Key Path field with an absolute path to the private key file on the server machine. If the key is encrypted, specify the passphrase in the corresponding field.

Convert line-endings to CRLF

Convert line-endings of all text files to CRLF (works as setting core.autocrlf=true in a repository config). When not selected, no line-endings conversion is performed (works as setting core.autocrlf=false). Affects the server-side checkout only. A change to this property causes a clean checkout.

Path to Git

Provide the path to a Git executable to be used on the agent. When set to %env.TEAMCITY_GIT_PATH%, the automatically detected Git will be used, see Git executable on the agent for details.

Checkout policy

This setting defines how TeamCity performs a checkout to a build agent.

• Use mirrors: recommended for long-lived agents. With this option selected, TeamCity creates a remote repository cache on the agent machine under the system/caches/git directory. The cache is then added as alternates when updating the build checkout directory. To speed up the following checkouts of this repository, the agent will reuse the cache in all the builds with the same fetch URL. This also speeds up clean checkout (as only the build working directory is cleaned) and saves disk space (as the mirror is the only clone of the given repository on the agent).

• Do not use mirrors: choose to check out right into the build checkout directory, without creating a mirror. Less optimal in terms of disk usage than mirrors, but preserved for backwards compatibility with existing configurations.

• Shallow clone: recommended for short-lived agents; for example, for disposable cloud agents being terminated after every build. Creates a shallow clone by fetching only one required revision, which allows saving time on the build start. Choose this option only if you do not require a Git commit history in your builds and if your cloud image does not contain a fresh Git mirror. You can enforce this option on certain agents by specifying the teamcity.git.shallowClone=true agent configuration property.

• Auto: TeamCity will automatically apply one of the above approaches depending on the teamcity.cloud.agent.terminate.after.build agent configuration property and on the mirror presence on the agent.

Clean Policy/Clean Files Policy

Specify here when the git clean command is to run on the agent, and which files are to be removed.

If a build configuration depends on multiple VCS roots, we suggest that you configure separate agent checkout directories for each of these roots, using VCS checkout rules. This way, git clean will never delete these checkout directories during cleaning.

teamcity.git.idle.timeout.seconds

1800

The idle timeout for communication with the remote repository. If no data were sent or received during this timeout, the plugin throws a timeout error to prevent hanging of the process forever.

teamcity.git.fetch.timeout

1800

(deprecated) Override of teamcity.git.idle.timeout.seconds for the git fetch operation

teamcity.git.fetch.separate.process

true

Defines whether TeamCity runs git fetch in a separate process

teamcity.git.fetch.process.max.memory

This property provides the explicit -Xmx and disables the automatic -Xmx setup.

Ensure the server machine has enough memory as the memory configured will be used in addition to the main server process and there can be several child processes doing git fetch and git patch, each using the configured amount of the memory. For large repositories requiring heap memory greater than -Xmx1024m for Git fetch, switching to 64-bit Java may be needed.

teamcity.git.fetch.process.max.memory.limit

By default, TeamCity starts nested Java processes for git fetch and git patch and automatically selects -Xmx for these processes.

This property specifies the maximum possible -Xmx value for git fetch or git patch that TeamCity can set automatically.

teamcity.git.monitoring.expiration.timeout.hours

24

teamcity.server.git.gc.enabled

false

Whether TeamCity should run git gc during the server clean-up (native git is used)

teamcity.server.git.executable.path

git

The path to the native git executable on the server. On Windows, remember to use double backslashes in the path.

teamcity.server.git.gc.quota.minutes

60

Maximum amount of time to run git gc

teamcity.git.cleanupCron

0 0 2 * * ? *

Cron expression for the time of a clean-up in git-plugin, by default — daily at 2AM.

teamcity.git.stream.file.threshold.mb

128

Threshold in megabytes after which JGit uses streams to inflate objects. Increase it if you have large binary files in the repository and see symptoms described in TW-14947

teamcity.git.buildPatchInSeparateProcess

true

Git-plugin builds patches in a separate process, set it to false to build patch in the server process. To build patch, git-plugin has to read repository files into memory. To not run out of memory git-plugin reads only objects of size smaller than the threshold, for larger objects streams are used and they can be slow (TW-14947). With patch building in a separate process all objects are read into memory. Patch process uses the memory settings of the separate fetch process.

teamcity.git.mirror.expiration.timeout.days

7

The number of days after which an unused clone of the repository will be removed from the server machine. The repository is considered unused if there were no TeamCity operations on this repository, like checking for changes or getting the current version. These operations are quite frequent, so 7 days is a reasonably high value.

teamcity.git.commit.debug.info

false

Defines whether to log additional debug info on each found commit.

teamcity.git.repackIdleTimeoutSeconds

1800

Defines the idle timeout of git-repack operations, in seconds. You might need to increase this timeout for large repositories as repacking objects in them takes a lot of time.

teamcity.git.sshProxyType

Type of SSH proxy, supported values: http, socks4, socks5. Keep in mind that socks4 proxy cannot resolve remote host names, so if you get an UnknownHostException, either switch to socks5 or add an entry for your git server into the hosts file on the TeamCity server machine.

teamcity.git.sshProxyHost

SSH proxy host

teamcity.git.sshProxyPort

SSH proxy port

teamcity.git.connectionRetryAttempts

3

Number of attempts to establish connection to the remote host for testing connection and getting a current repository state before admitting a failure

teamcity.git.connectionRetryIntervalSeconds

4

Interval in seconds between connection attempts

teamcity.git.use.native.ssh

false

When checkout on agent: whether TeamCity should use native SSH implementation.

teamcity.git.idle.timeout.seconds

3600

The idle timeout for the git fetch operation when the agent-side checkout is used. The fetch is terminated if there is no output from the fetch process during this time.