REST API: Getting last build status of each build configuration

I'm starting a new build lights project where I'll be using the REST API.

I want to get the last status for each build configuration. Currently, the only way I see, is to get the list of all build configurations, cycling over them, and retrieving the last build status. Is there perhaps a simpler way, e.g. by making one REST call?

Then, are there any pointers on best practices to poll the REST API? There is a bit of a trade-off, as one does not want to poll too often. This can be minimised somewhat by keeping HTTP connections open, which will reduce network IO overheads, but of course the number of requests will remain the same. What would a typical good/sane polling interval be?

What I've done before, was to build a server plugin and to push build events, but building such a system is a lot more complex, which makes it difficult for others to use my project, so I'd like to go for this simpler approach.

5 comments
Comment actions Permalink

Hi,

We have a related feature request, in this comment an experimental approach implemented in TeamCity 8.1 is described. Please try it, your feedback is highly appreciated.
Currently each request needs to be performed as a separate HTTP request, please watch and vote for related feature request.
Could you please describe your use case in more details? Why do you need to get the status of last build of each build configuration?

0
Comment actions Permalink

Thank you for the information, Alina.

I have read the issue and comments, and I will experiment with that functionality.

I have built some other plugins, among which a personal build light (also know as feedback devices). That project, unfortunately, was much too complex, because of the way I built it. So I've started working on a simpler system, and was hoping to avoid having to build a plugin. The reason I want to avoid that, is that for real-time feedback I will need to maintain a persistent socket from the client software that drives the build light, to the server plugin. The other option is that the devices registers with the build server plugin with its address, and the server can then connect to the client (which is backwards) when there is a build event (so the client software must host a listening socket to receive connections).

Hence, I wanted to poll the REST API, but there are of course drawbacks, such as latency and overheads. And building a plugin has some obvious advantages, such as user notification customisation.

The "problem" using a build light, is of course that it can convey only global status: E.g. when it's red, it means that one or more builds you are watching/have contributed to are in a failing state. Green would imply everything's ok and yellow may mean something (again, at least one) build configuration is running. Either way, some form of cached state must be maintained per user.

I've tried to find the source for the Windows Tray Notifier many times before to see how that is built, but to no avail, but from sniffing the network it just seems to make long-lived AJAX calls (comet-style). I'm thinking the various IDE plugins for IntelliJ, WebStorm, etc., etc. does something similar. It would help a lot to know how those plugins are built.

0
Comment actions Permalink

Pieter,

Using repetative HTTP requests seems a good enough approach. I'd just consider reusing authentication. Performing a request something like each 10 seconds seems OK and shoulkd provide fast enough responsiveness for the most of cases.

AFAIK Windows Tray notifier and IDE plugins do just that, just setting keep-alive for the HTTP connection, sending new HTTP requests periodically. This is also how TeamCity web UI works and we are only adding support for some comet-like requests in web UI in TeamCity 9.0.

Sources of the tray notifier and IDE plugins are not publicly available at this time, but I do not think they would be of much help. You can always route their traffic through a logging HTTP proxy (like Fiddler for Windows) and study HTTP requests, if necessary.

BTW, have you considered publishing your project so that other TeamCity users can benefit from it?

0
Comment actions Permalink

Hi Yegor

As always, thank you for the information. I will then keep going with the REST API approach, taking note of the authorization performance.

You're welcome to monitor my progress on GitHub: https://github.com/parautenbach/TeamCity-Build-Light. I've only created the skeleton and some USB classes so far, and will hopefully pick up speed soon. I will definitely be in contact to publish this once it's in beta.

I will be re-using code, mostly from a previous project: https://github.com/parautenbach/Build-Lights-Client-Python. That required a lightweight plugin for TC (https://github.com/parautenbach/TeamCity-Notifier-Plugin) which posted events to a custom server (https://github.com/parautenbach/Build-Lights-Server-and-Client) which broadcasted information to subscribed clients that acted as the controller for a USB device connected to a developer's PC. That worked really well, but I think was too complex for most to get going, especially dealing with all the cross-platform issues. I'm hoping that my new project would be more platform agnostic, working on Linux, OS X and Windows.

(Btw, my HipChat TC plugin seems to be quite popular: https://github.com/parautenbach/TeamCity-HipChat-Notifier. It is already on your list of plugins.)

0
Comment actions Permalink

Peiter,

Thank you for the description!

Good luck with the project and yes, please keep us updated.

0

Please sign in to leave a comment.