Monthly Archives: April 2009

Creating a TeamCity currently failed builds page

Frustrated with seeing too many failed builds and wanting to make the issue more visible we are planning on putting an LCD monitor on the wall to display all the failing builds. However, unfortunately TeamCity does not have such a page available. There are various ways of receiving the status of builds such as through RSS feeds and the Status Widget, but the information is no more than you can see on the overview page and if you have a lot of builds it’s not easy to see where the problems are.

First, I experimented with using Linq to mine the RSS feeds and was getting somewhere but it wasn’t exactly a five minute job. Then Kirill Maximov, a JetBrains TeamCity developer responded to my cries of help on Twitter saying I could modify the External Status Widget and a whole world of fun was opened up to me.

How to create a failed builds page

  1. Create an html page that includes the External Status Widget as described here. By default this page will only show the current status of all projects as you see on the overview page, but we only want to know about failed builds.
  2. Add the wrapping <c:if test=”${not buildType.status.successful}”></c:if> to the file *TeamCity*/webapps/ROOT/status/externalStatus.jsp (it is probably worth making a backup of this file first).
  3. Thats it! However as you have now realised you can do a lot more customisation. If you have a root through some of the jsp files you’ll see there are a lot of features you can take advantage of to customise further.

You can download my html page and modifed externalStatus.jsp files here

Team principles

On my new team we’ve just started our first proper iteration. We’ve agreed to commit to the following principles:

  • No multi-tasking
  • All new or changed code must be thoroughly unit tested
  • No more than 2 pieces of work in “Active Work” at any time (our team is 3 developers)
  • We always work on the highest priority task
  • Our definition of done is “In UAT”
  • Leave it in a better condition than you found it
  • No hidden work
  • No overtime
  • No disruptions
  • Don’t SysTest your own work (we don’t have a tester yet)
Have you done something similar? What are your team’s principles?