Inconsistency between RestAPI and teamcity.build.triggeredBy parameter

I'm seeing what I think is an inconsistency in what the teamcity.build.triggeredBy parameter and the Rest API reports. This is in Version 9.0.1 of Teamcity.

I have a build hierarchy, where MyBuild has a number of dependencies. If one of those dependencies re-builds, then MyBuild will rebuild. My goal is, via the Rest API, to be able to figure out why MyBuild rebuilt. Maybe it was a VCS change, or maybe it was because a dependency rebuilt. And if it was the latter, why did the dependency rebuild? Recurse to completion.

Looking via the web UI, I see that the parameter teamcity.build.triggeredBy gives me the name and build number of the dependency that caused my build to run.

But, if I look at my build via the rest API, /guestAuth/app/rest/buildTypes/id:MyBuild/builds/id:XXXXX

I see <triggered type="unknown" details="##triggeredByBuildType='bt196' triggeredByBuild='0.0.5.93'" date="20150309T152756-0400"/>

The triggeredByBuild attribute is correct, but the details attribute does not match the build type that 's reported by the parameter referenced above.

If I look via the Rest API for that specific build type id (/guest/auth/rest/buildTypes/id:bt196) , it's not found. Yet, in the administration page of the web-ui, if I filter the root project for bt196, the correct subproject _is_ found.

So, bt196 is known about, but somehow I can't use it via the Rest API to find the build details to see why my dependent build ran.

Am I doing this right, or is there a bug somewhere?

6 comments
Comment actions Permalink

Hi Stephen,


"bt196" is an internal id. Please use the following request to get info about this build configuration:

http://teamcity:8111/httpAuth/app/rest/buildTypes/internalId:bt196

I've create the usability problem issue in our tracker https://youtrack.jetbrains.com/issue/TW-40385, please watch/vote for it.

0
Comment actions Permalink

Hi Stephen,

Actually, relying on the triggered by information is quite fragile - there might be several builds queued, then merged and only one of them can finally run (so you get almost random "triggered by" in this case). Also, build can be re-queued after unexpected finish, etc.

I'd say that "triggered by" is provided more for hte informational purposes, it is not recommended to rely any logic on it.

In this specific case it seems you are using finish build trigger and at this time there is not enough information stored in TeamCity to correctly represent the build which was used as the trigger event.

You can use the "details" field, but it's presentation is internal and it will be changed int he future TeamCity versions without specific notes. In particular, TW-33360 is related. If you still want to use it, the build configuration can be found by the internal id via request like /app/rest/buildTypes/internalId:btNNN

Could you please detail why do you need the logic to determine why MyBuild is rebuilt?

0
Comment actions Permalink

Thank you for the response.

I have deeply nested builds, a change to any one of which could cause builds that depend on it to rebuild.... cascading up to a final build that produces a releaseable artifact.

At one extreme, someone could change how make runs internal commands, which would result in a new internal tool library, which would trigger the open source libraries we build to be re-built. Which, in turn would trigger our SDK library to be rebuilt, which would cause our application to be rebuilt which (finally) would result in a new product build.

At the other extreme, someone could make a change in how product packaging works; and only the new product build results.

What I want to do is see why a new releaseable artifact was created. IE, who made what change where; or in other words, what change in what vcs root resulted in a new releaseable artifact.

I can do this by drilling down thru the webUI; but that can take time, and what I'd like is a report that is published as an artifact along with the release candidate. The report, answering the question - what change in what vcs root caused this new release candidate to be build.

If there's a different way to do this, I'm open to suggestions.

HTH, and many thanks!

0
Comment actions Permalink

Stephen,

Thank you for the detailed descirption!

If you only care about changes coming from VCS, you can try enabling "Show changes from snapshot dependencies" option on the VCS settings of the final release producing build configuration: this will include the revision and the individual changes from the entire build chain onto the CHanges tab of the release build.

Does this sound helpful for addressing your needs?

0
Comment actions Permalink

I'll give it a try and see.

Note, that the dependencies I set up are not snapshot dependencies - admittedly I'm confused about what those are.

If this makes a difference, let me know and if you have suggestions on how to better understand snapshot dependencies, please let me know. I have a passing understanding from my Maven days; but am currently in a pure c/c++ world where things are a little different :)

0
Comment actions Permalink

Stephen,

TeamCity snapshot dependnecies are not related to Maven's ones. Please check the doc and experiment with them, they provide a powerful tool for working with builds which depnd one on another.

0

Please sign in to leave a comment.