Reference top-level Matrix build from generated builds
I'm looking for a way to refer to the top-level build of a matrix build from the generated builds it creates. For example, I want to include the URL of the top-level build in the artifacts produced by the generated builds. I'd also like a way to add a tag to the top-level build (eg using the REST API, which would need the build ID).
Unfortunately there doesn't appear to be any link back from the generated builds to the top-level build that created them. I've looked in their parameters, and also at the output of the build details API for the generated builds. There's a snapshot dependency from the top-level down to the generated builds, but nothing in the opposite direction.
Is there an easy way to achieve this?
Please sign in to leave a comment.
I don't think there is a direct parameter referencing the parent build ID.
The closest I can suggest is to check the REST API.
Build IDs are assigned as soon as a build is added to the queue, so it should be possible for you to query the REST API for running builds of a set buildTypeId (build type ID of the parent build). Each returned build will have a list of "virtual" dependencies with their IDs. If the current build can be found within the listed dependencies, then it's a correct parent build.
Let me know if this answers your questions.
Best regards,
Anton
Thanks Anton,
I've just about got something working with the REST API, but it's pretty clunky. I'm using this locator:
buildType:(id:<BTID>),snapshotDependency:(from:(id:<ID>)),defaultFilter:falseWhere <BTID> is replaced by the buildTypeId of the top-level project, and <ID> by the generated build's ID. That matches the top-level matrix build and excludes any other dependents.
It works, but I need to do some string processing to extract <BTID> from a parameter in the generated build. The options I found are:
<BTID>_virtual_1234567890_1<BTID>_virtualbt:<BTID>Update: I also found that Build Credentials for the generated build don't have permission to modify the top level build. Unsurprising as the build ID is different, but a little inconvenient.
This approach works well when you know the ID of the parent build configuration beforehand.
In other cases, yes, some string processing is required. I would suggest teamcity.internal.original.link.id parameter for that.
Best regards,
Anton
Hi Anton,
There seems to be some conflict with
teamcity.internal.original.link.id. If I try to reference that it appears in the config's parameter list with “<value is required>”, but setting a default value doesn't work.teamcity.project.idworks fine though.Do you know if there's any way around the build authentication issue, or will I need to create a user account with a suitable access token to update the top-level build?
teamcity.internal.original.link.id shouldn't be modified. I suggested it to get the build configuration ID of the parent build. Could you provide more details on what you want to achieve and why you need to modify it?
And please let me know the details about the build authentication issue you encountered.
Best regards,
Anton
The value of
teamcity.internal.original.link.idappears to be the buildTypeId of the original config, but it has a prefix of “bt:”I assumed that prefix would need to be removed so that the REST request would find the correct build.
In any case, I found it impossible to reference that parameter from a build step, as doing so causes a “<value is required>” error, which blocks any attempt to run the config.
teamcity.internal.original.link.id is not a predefined build parameter, so it can't be referenced as a parameter.
If you don't know the ID of the parent build configuration, one option is to send a REST API request to retrieve the current build first and extract the teamcity.internal.original.link.id from it.
Or use the teamcity.project.id or system.teamcity.buildType.id predefined build parameter.
It's not possible to change the value of these parameters.
Best regards,
Anton