Retrieving VCS root url with build user %system.teamcity.auth.userId%
I have a use case for retrieving information about the build's origin via the API by using the built in build user credentials (%system.teamcity.auth.userId% and %system.teamcity.auth.password%). However, this user doesn't seem to have permissions to retrieve information about the VCS root. I am specifically interested in the repository's url, which can be found in the vcsroot.url build parameter or the url parameter of the VCS root entity itself.
I would like to know:
- what permissions this built in user already has?
- is it possible to extend/tweak the permissions for this user?
- is there another way to retrieve the origin's repository url via the API? (without creating a dedicated user/token; I would to avoid that if possible)
Please sign in to leave a comment.
This "build user" has the following permissions:
Global permissions:
- VIEW_PROJECT
- VIEW_BUILD_RUNTIME_DATA
Build's project permissions:
- VIEW_FILE_CONTENT
- CANCEL_BUILD
- TAG_BUILD
- PIN_UNPIN_BUILD
- RUN_BUILD
Build's VCS root's projects permissions:
- VIEW_FILE_CONTENT
These permissions are not changeable.
Could you provide more details on your use case? Maybe I could help with some workaround.
Best regards,
Anton
Hi Anton,
thank you for the quick response. Our use case is as follows:
We are building an integration for TeamCity. This integration consists of a TeamCity build runner plugin and a backend service that is hosted elsewhere. The backend service is supposed to collect various metadata about a running TeamCity build from the TeamCity API (the information must be reliable and trusted; therefore we want to retrieve it from the API and we can't rely on the build runner sending the information). The build runner is supposed to send the build ID to the backend service and the backend service would talk to the API to do its thing.
Of course, the backend service needs to be authenticated against the TeamCity API. We want to avoid creating/managing service users and credentials as much as possible. The provided credentials seemed very convenient for this architecture, since they are ephemeral and unique to every build, which makes the entire thing stateless. In summary, the workflow we want to implement is:
At minimum, we want to retrieve information about the VCS root and source code state that was used in the build, this includes:
commit id, git repo url, branch name. This is where we ran into limitations, because we can't retrieve the repo url through the API.
I hope this explanation makes sense.
It is indeed possible. I was using the wrong fields apparently
Build.VcsRoot.Properties["url"] and Build.Properties["vcsroot.url"] didn't work. However, Build.ResultingProperties["vcsroot.url"] did the job. Thank you
Hi again Anton Vakhtel!
(This might not be related to the original question - I can happily move this discussion into another thread)
We realized that can't rely on any information that we retrieve from the build's properties (resultingProperties, originalProperties, startProeprties), because they can be overridden by the user with arbitrary values, either programmatically or through the UI when starting a build. The Build api does have a customization property that (if I understood it correctly), should give us a list of overridden values (see https://www.jetbrains.com/help/teamcity/rest/build.html#customization). However, when I retrieve the customization for a build, the result set is always empty. Is this expected behavior? Is there a way to know whether a property value was overridden by the user/build?
The resultingProperties looks like what you are looking for:
Returns the complete list of predefined and custom properties with their final values. Final values are those reported by a build agent after a build finishes. These include values changed during a build and via the Run Custom Build dialog.
For the build where the customization is empty, what is the value of customized?
Best regards,
Anton
Not really, since a user can override a predefined property through the Run Custom Build Dialog. In my use case, I want to retrieve the original value of vcsroot.url property as it was reported by the agent (the actual repository url of the vcs root). If a user provides a custom property with the same name but with a different value through the Run Custom Build dialog, then the user's input will end up in the resultingProperties and I have no way of knowing this through the API.
The value is true. This is I am surpised that no customizations are returned
Indeed, the resultingProperties returns a final set of properties. Sorry that I misunderstood your requirement, but there are also originalProperties and startProperties. It looks like originalProperties should return all original, default, values: https://www.jetbrains.com/help/teamcity/rest/build.html#originalProperties.
Regarding the customization: I will try to reproduce it and get back to you.
Best regards,
Anton
Hi Taha,
Sorry for the wait. Regarding the customization property, it looks like a bug, so I created the issue in our issue tracker: https://youtrack.jetbrains.com/issue/TW-91557. Please vote for it and subscribe to receive updates.
While the customization property doesn't return parameters that were customized, as a workaround, you could try the following:
You should get the result like this one:
Please let me know if you have any additional questions.
Best regards,
Anton
Hi Anton,
thank you for confirming this behavior of customization property and creating an issue. As for you suggested workaround, I actually can't retrieve the vcsroot.url via the originalProperties property. Maybe because vcsroot.url is not an actual property of the build and it was reported by an external entity (the vcs root in the case) to the build after the build has started, and therefore it's not an “original property”
Yes, you're right for this parameter. It's not known before the build starts, so it's not present in the originalProperties.
I see one straightforward but not-so-elegant solution: a separate build configuration parameter with an explicit VCS root URL value (referencing %vcsroot.url% as its value won't help in this case as well, as it's not resolved before the build is started).
This way, you would be able to either use this added parameter (and see its changes) or use the vcsroot.url parameter and compare it to this added parameter (while also checking its customizations).
The best way would still be to use a separate access token for REST API requests and get actual VCS root parameters rather than build parameters. It looks like this built-in build user is not very suitable for these requirements.
Best regards,
Anton