VcsRoot
A VCS root stores repository connection settings. TeamCity uses VCS roots to create VcsRootInstance objects, enabling build configurations and features to interact with remote repositories for source checkout, build status publishing, and more.
Related Help article: Configuring VCS Roots
Properties
id
The unique ID of the root. Typically consists of trunkated parent project ID and root name.
internalId
The internal read-only ID of the root.
uuid
The internal read-only UUID of the root.
name
The public root name displayed in TeamCity UI.
vcsName
The type of a VCS provider to which this root connects.
modificationCheckInterval
The interval (in seconds) for polling VCS for new changes. Equals null if this root uses default server polling interval.
href
The short (without the TeamCity server address) link to this VCS root.
project
The TeamCity project that owns this VCS root.
properties
The list of VCS root settings, such as clean policy, auth method, default repository branch name, and more.
vcsRootInstances
The list of VcsRootInstance objects spawned from this VCS root. If all root settings are static, it produces one root instance that can be attached to one or multiple configurations. In turn, if some of the root settings use parameter references (for example, {'name':'branch','value':'%main-branch%'}), a different VcsRootInstance is spawned for each build configuration that has a unique main-branch property value. In this case a single VcsRoot has multiple corresponding VcsRootInstances.
repositoryIdStrings
The list of internally used repository IDs.
locator
The part of the href property value that specifies the object locator. Ommitted from regular responses.
projectLocator
This property is deprecated.
connectionId
Optional ID of a project connection to use for authentication when creating a new VCS root. Used only for POST; not returned.
Schema
Below, you can find a full schema of this object, in XML and JSON formats. You can choose what fields to submit depending on your current needs. Different methods might expect different fields: the best approach is to request this entity via GET and use the response as a base for the following POST request.
A link to another object implies that you can substitute it with the schema of the linked object, if it is required for your call.