If you’re using a Continuous Integration tool, you should also be using an information radiator like Pivotal Labs’ CiMonitor. CiMonitor is designed to be displayed on a screen that the entire team can see. If any of your builds go red, it shows up as a big red square and the team can quickly respond.

CiMonitor has long had support for CruiseControl.rb and Jenkins (formerly Hudson). However, my CI tool of choice is TeamCity from JetBrains. We’ve recently added native support in CiMonitor for displaying your TeamCity build status, and I want to show you how to get it going. It’s as easy as configuring a new project and pointing to TeamCity’s REST API. Let’s walk through it step by step.

Install CiMonitor

For native TeamCity support, you’ll need to be on the latest version of CiMonitor. Follow the installation instructions on the CiMonitor GitHub page. If you already have CiMonitor installed locally, you’ll have to update to the latest version.

Create a New Project

Choose “Team City Rest Project” as the Project Type.

For the Feed URL, you’ll be hitting the REST API provided by TeamCity 5.0 and newer. The correct format for the URL is as follows, with the # representing the TeamCity project number:

http://teamcity:8111/app/rest/builds?locator=running:all,buildType:(id:bt#)

You can find the correct project number by clicking onto the project in TeamCity and looking in the URL. Grab the number from the buildTypeId parameter.
TeamCity Project ID

You will also need to fill in a TeamCity username and password that CiMonitor will use to access the REST API.

Example Settings

New Project

Once you’ve set up the new project, save it and you’re all set.

Watch Your Builds Run!

You can now easily see the status of your TeamCity builds.

CiMonitor will also show that a build is currently in progress.
Running TeamCity Build

Wrapping Up

The integration is pretty solid, but there are one or two things that may seem to be odd behavior.

CiMonitor keeps track of build start times to control the size of the build dots for each project. The older the build, the smaller the dot. Currently, TeamCity’s REST API doesn’t publish the start time of a running build. Since this data is unavailable, CiMonitor just uses the current time when it fetches the feed. This is a minor issue, and JetBrains has already committed a fix for their REST API which will be released in the next version of TeamCity. CiMonitor will use the new field if it’s present in the feed.

Also, TeamCity has a great feature that will tell you that a build is failing before it even finishes. This has an interesting effect on CiMonitor. If a TeamCity build is red, the next time it begins running, CiMonitor will show it as green until the first test fails. Once TeamCity picks up on a failure, CiMonitor will show the build as red. This can be a little confusing at first because it may look like a build-in-progress is green before it has finished.

Hopefully you find this new functionality useful!

Interesting:

bundle install --without test excludes the test group in your Gemfile from the install. It works well for reducing the size of your Heroku slug. However, there’s a glitch with this option on Heroku — when you specify it, Heroku reinstalls every included gem every time you deploy. It does respect your Gemfile.lock, so you’re trading a smaller slug for a longer deploy.
Pivotal’s open source CIMonitor project now supports OpenID! Thanks Tyler and Josh.
Arel has a bug that makes it difficult to use in rails console. Every time you add a predicate, the number of internal objects in the Arel result increases exponentially. So, by the time you have 5 or 6 predicates, the console finishes generating the expression more or less instantly, and then spends 15+ minutes calling to_s on the resulting Arel object in order to display it to you. tl;dr: when you’re playing with Arel in rails console, end every line with ; nil to avoid having it print out the result. The exponential object explosion will be fixed in Rails 3.1.

Pivotal Labs

Radiating your TeamCity Builds