I’ve long been a fan of the python-based ticket tracking/wiki/subversion browser, trac. It manages to integrate subversion changesets with tickets quite simply – go to a changset page and you’ll see the edits; go to a ticket and you can see all changesets that apply to the ticket. On top of that you can use wiki syntax in your subversion commit messages (or anywhere for that matter) – to my mind trac is perfectly capable of doing away with the need for separate systems (certainly on my next project I’ll be recommending trac over a Jira/Wiki/ViewCVS or FishEye combination).
I’ve long been a critic of the CruiseControl reporting application. Whilst the underlying build-loop is fairly solid, the separate reporting application lacks features, is slow, and is in need of some UI love. With the new 0.9 development, edgewall have added a plugin architecture. Ditching the CruiseControl reporting application in favour of a system which is fully integrated with your changset and ticket monitoring system seemed like an obvious next step, so I spent the weekend working on a spike to do just that.
The overall aims of the plugin are:
- To show CruiseControl builds in trac’s timeline, alongside wiki edits, ticket changes and SVN modifications.
- To have a page for each build which can be linked to using trac’s wiki syntax as with tickets and changsets
- The build page should show the same information as the existing reporting application
- It should be faster than the existing XSLT-driven reporting application
- When looking at a ticket, you should be able to see what builds apply to it (this for me is the real killer feature)
- Going forward, the plugin should work with other Continuous Integration tools (top of the list will probably CC.Net)
As you can see from the above image, integration into the timeline was fairly easy. Currently when the timeline is requested, my simple SAX-based cruise log file parser pulls out the relevant information. The next step here is to place this information in trac’s built-in SQLite DB (which should take care of the ‘being faster than XSLT’ requirement). I may even create a plugin for CruiseControl so it can ‘push’ build results to trac in a cleaner, more efficient manner than parsing the XML files (a simple REST webservice for trac should do the job here – trac already seems pretty RESTful). A page for each build is probably my next priority though. The only unknown at present is whether or not I can integrate the builds into the ticket view – the plugin API doesn’t seem to expose any hooks here, but I’ll raise the issue with the trac developers and see what they think.
Anyway, feedback on what CruiseControl users would like to see by way of features would be appreciated – as would anyone willing to test it. As I said, it is a spike right now – I’ll probably start reimplementing it tonight – but you’re welcome to play around with what I have right now (if you have the latest version of trac from subversion, installing the plugin should be a breeze).Advertisements