Monitoring builds and adding a build light
![]()
I would like to add a (real) build light that shows the current state of the build (red or green). I have done this before using other continuous integration tools but this is the first time I have tried it with RTC.
Can anyone recommend a way of getting the current state of a given build definition from outside RTC? I would like to know whether there is a build in progress, and also whether the previous build was successful or failed. I have had a quick look at the feeds url for a build definition but for some reason not all the build events are available from the external feed. There are some events (including the important Status:Failed, State: Completed) not appearing when I look at the feed from a browser, although they appear inside RTC. We are using RTC 2.0.0.2. Any help would be appreciated. Thanks, Colin. |
One answer
![]()
Hi Colin,
Sorry for the delay, I must have missed this post when scanning the forums last week. Using the build feeds would be a good approach (note that you can create a feed for each build definition). Each event should carry the state and status, as well as the build label, build definition id, and whether it was a personal build (you might want to filter these out). e.g. the feed for the rtc.jcb build, https://jazzdev.torolab.ibm.com:9443/jazz/service/com.ibm.team.repository.common.internal.IFeedService?provider=build&buildDefinitionUUID=_AHLqcIkAEd6RvINWj6hoDw&user=nedgar has:
When you see the status and/or state missing, are you looking at the HTML rendering of the feed or the original XML? They should be on every entry. Another approach is to use the internal REST interface that services the web UI. e.g.: https://jazz.net/jazz/resource/virtual/build/definitionstatusrecords?profile=REDUCED comes back in JSON format, and has:
The 'lastCompletedBuildStatus shows the status of the last completed build, excluding personal builds. I think the latter approach may be more complicated for authentication though, if your server is configured for form-based authentication. I believe the feeds always use HTTP auth, which is simpler. |