Determining the Effective VCS Root Configuration Commit ID per Build
I have a use case where I need to reliably determine which VCS Root configuration commit ID (version) was used for any given build, assuming that Versioned Settings are enabled for the project. When a single VCS Root is used for both the project and the Build Configuration, this is not possible, and there is no REST API way to determine which VCS Root configuration commit ID (version) was actually used if the latest Kotlin DSL settings are broken and TeamCity falls back to the last known good settings.
Workaround
`versionedSettingsRevision` is only returned in the REST API when the build uses a dedicated VCS Root configuration separate from the Project Versioned Settings VCS Root, even if both point to the same repository.
If a single VCS Root is shared, `versionedSettingsRevision` is not available in the API. Hence, there is no reliable way to determine which VCS Root configuration commit ID (version) was actually used.
Expected Behavior
Assuming that Versioned Settings are enabled for the project, the REST API should always expose the effective VCS Root configuration commit ID (version) used for a build, regardless of:
* Whether VCS Roots are shared or separate
* Whether TeamCity uses the current or the last known good versioned settings
Question
Is this intended behavior, a known limitation, or a bug?
Please sign in to leave a comment.
Hi Saleh,
Sorry for the delayed response.
Based on my understanding, this appears to be a limitation. Please refer to the official documentation below for more details:
https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Displaying+Changes
If you store versioned settings in a separate VCS root, not the one which is directly attached to your build configurations, then when turned ON this checkbox starts showing changes made to these VCS roots. If VCS root is already attached to your configuration, then it does nothing.
I have reached out to our development team to confirm this behavior.
Thank you for your patience and cooperation.
Thanks for your patience — I checked with the development team regarding the parsing behavior.
Yes — the current implementation works in the way you described.
Additionally, we had filed a ticket internally to track this. Thanks for your understanding.
Hi Tom,
Thank you for confirming this with the development team and for filing an internal ticket to track this limitation.
I appreciate the clarification on the current behavior. To help us plan accordingly, I have a few follow-up questions:
Thank you again for your help and for escalating this to the development team. I understand these things take time, and I really appreciate your assistance.
You are welcome.
Please see the details below regarding your follow-up questions:
At the moment, this issue is not in our active backlog, so we are unable to provide a specific ETA. That said, the ticket is being monitored internally. For reference, it is tracked under ticket TW-94824, which is not publicly accessible.
Reaching out via your TeamCity Enterprise support channel is definitely a reasonable approach. However, please note that prioritization ultimately depends on the development team’s current workload and overall priorities, so we cannot guarantee a change in priority.
We will keep you informed if there are any significant updates. You may also want to monitor our official release notes for announcements:
https://www.jetbrains.com/help/teamcity/upgrade-notes.html
Thank you for your cooperation and understanding.