Determining the Effective Settings Path in VCS per Build

I have a use case where I need to reliably determine what “Settings path in VCS” was used for any given build, assuming that Versioned Settings are enabled for the project.

Current Behavior:

“Settings path in VCS” is currently tied to the project level rather than individual builds. This means there's no reliable way to determine which Settings path in VCS was actually used for a specific historical build.

The Problem:

Since the Settings path in VCS can be changed throughout the lifetime of a project, I cannot retroactively determine what Settings path was effective at the time a particular build was executed. This creates challenges for:

  • Troubleshooting historical builds
  • Understanding configuration changes over time

Expected Behavior:

I would expect to be able to determine the effective Settings path in VCS on a per-build basis, not just at the project level. Ideally, this information can be retrieved via the TeamCity Builds REST API so I can determine exactly what “Settings path in VCS” was used for any given build.

Question:

Is this current behavior:

  1. Intended behavior/by design?
  2. A known limitation that may be addressed in a future release?
  3. A bug that should be fixed?

Are there any workarounds or alternative approaches to achieve this?

Thank you for your assistance.

2
1 comment

Hi,

Thank you for the detailed explanation and for clearly describing your use case.

Your observation is correct: TeamCity currently treats the “Settings path in VCS” as a project-level configuration rather than a per-build property. Because this value is not snapshotted into a build’s metadata, there is no dedicated field in the REST API (such as settingsPath) that allows you to retroactively determine which settings path was effective at the time a specific historical build was executed.

> Are there any workarounds or alternative approaches to achieve this?

1.Inspect the effective settings snapshot stored for a build

For each build, TeamCity stores a snapshot of the configuration that was actually used during execution. You can inspect the following internal directory on the TeamCity server:

<TeamCity Data Directory>/system/artifacts/<Project ID>/<Build Configuration ID>/<Build ID>/.teamcity/settings

While this directory does not explicitly record the name of the “Settings path in VCS”, it does contain the exact .xml or .kts files that were effective for that build

By comparing these files with your VCS repository structure, you can infer which settings directory the configuration was loaded from at the time.

Please note that this approach is mainly suitable for troubleshooting or manual inspection..

2. To ensure that every future build permanently records the "Settings path in VCS" used, you can add a script-based step to your build process. This script queries the current project configuration and "locks" the path into a Build Parameter.

Below is an example PowerShell script that can be used in a PowerShell build step. The recorded parameters can later be retrieved via:

http(s)://<server>/app/rest/builds/id:<BUILD_ID>/resulting-properties/<parameterName>

PowShell code: 

# 1. Basic Variables $serverUrl = "%teamcity.serverUrl%".TrimEnd('/')
$projectId = "%teamcity.project.id%"
# The user must have permission to view the project settings.
# The username and password must be defined as parameters with assigned values.
$user = "%user%"
$pass = "%password%"

# 2. Authentication and Headers (Explicitly require JSON) $pair = "${user}:${pass}"
$encoded = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes($pair))
$headers = @{
"Authorization" = "Basic $encoded"
"Accept"        = "application/json"
}

# 3. Request Interface $url = "$serverUrl/app/rest/projects/id:$projectId/versionedSettings/config"

try {
# --- Step A: Obtain the versioning settings configuration (including vcsRootId and path) --- $configUrl = "$serverUrl/httpAuth/app/rest/projects/id:$projectId/versionedSettings/config"
$config = Invoke-RestMethod -Uri $configUrl -Headers $headers -Method Get

$vcsRootId = $config.vcsRootId
$vcsPath = if ($null -ne $config.settingsPath) { $config.settingsPath } else { ".teamcity" }

Write-Host "Detected vcsRootId: $vcsRootId"
Write-Host "Detected Settings Path: $vcsPath" 
# --- Step B: Retrieve repository details based on vcsRootId ---

# Note: Here, using the id:$vcsRootId ensures precise location. 
$vcsRootUrl = "$serverUrl/app/rest/vcs-roots/id:$vcsRootId"
$vcsDetail = Invoke-RestMethod -Uri $vcsRootUrl -Headers $headers -Method Get

# In TeamCity, the URL is stored in the property array of the "properties" section, with the name "url" , you also can store the properties you want.

$repoUrl = ($vcsDetail.properties.property | Where-Object { $_.name -eq "url" }).value
# Also obtain branch information 
$branch = ($vcsDetail.properties.property | Where-Object { $_.name -eq "branch" }).value

Write-Host "Detected repository URL: $repoUrl"
Write-Host "Detected default branch: $branch" 
# --- Step C: Lock these key information into the build parameters ---
# This way, when you look at any historical build in the future, you can directly see the paths, repositories, and branches used at that time. 
# You also need to define the related parameters in the build configuration.
Write-Host "##teamcity[setParameter name='vcs_settings_path' value='$vcsPath']"
Write-Host "##teamcity[setParameter name='vcs_settings_repository' value='$repoUrl']"
Write-Host "##teamcity[setParameter name='vcs_settings_root_id' value='$vcsRootId']"
Write-Host "##teamcity[setParameter name='branch' value='$branch']"
} catch {
Write-Error "Failed to obtain VCS information: $_" }

With this approach, each build will permanently record:

  • The settings path in VCS
  • The VCS root ID
  • The repository URL
  • The branch used

This information will then be easily accessible via the REST API: http(s)://<server>/app/rest/builds/id:<BUILD_ID>/resulting-properties/<parameterName>

Please note that this script is provided as a reference example only.
It is not an officially supported TeamCity solution, and we are unable to provide maintenance or long-term support for custom scripts.

Best Regards,

Tom

0

Please sign in to leave a comment.