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).
magpiebrain 
14 Responses to “A CruiseControl plugin for trac”
This is really a great feature! I look forward to using CruiseControl.Net with Trac when you are done.
Many thanks!
The REST API has moved up my priority list, so it’ll be the next thing I look at – hopefully this means we can work on CruiseControl and CC.NET integration in parallel…
This will be great! I’m just setting up a CI system for a .net project at the moment. We are already using SVN/Trac so everything should be integrated by the time I get there! Thanks very much for your efforts.
Thanks Felix – lets hope I (hopefully _we_) can turn this around in a couple of weeks 🙂
Sam, we (Viewtier) are currently considering introducing a plugin architecture for Parabuild server. We’ll appreciate if you take alook at the current architecture.
— AlexP
That’s interesting Alex – out of interest how does Parabuild compare to other Continuous Integration tools such as CruiseControl/CC.Net et al? There is a good CI tool “comparison matrix”:http://docs.codehaus.org/display/DAMAGECONTROL/Continuous+Integration+Server+Feature+Matrix
you could get yourselves added to – would help with the marketing if nothing else!
I couldn’t see any documentation detailing your plugin architecture – but if you support pluggable result publishers like CruiseControl, then integrating with a trac plugin that exposes a REST API would be trivially simple.
Sam,
Parabuild is fully configurable through Web UI, supports remote builds to offload the “main” build server and takes 15 minutes to first build run. There is also a bunch of other features that make Parabuild production-grade build management server.
As for the plugin API – it is under development yet. Would you be interested to be notified when it is available for public use?
That would be good – thanks. My priority is for the trac plugin to work well with CruiseControl initially and CC.Net shortly after, as these are the tools I tend to use most. The fact that the plugins for both tools will be opensource should make it very easy to reuse the code to create a plugin for Parabuild once your plugin API is finalised.
This is brilliant. It is exactly what I have been looking for and the one critical piece that I felt Trac was missing. For a while I thought of trying to do some kind of integration like this between Roundup, Subversion, and Luntbuild, but looks like you saved me the trouble. However, if you are looking for other build tools to integrate with, Luntbuild would be on my short list.
A REST API should make integration with other tools fairly simple – does LuntBuild have a plugin API?
Cool stuff! I’ve added a link to this page to the new “3rd party” section on the CC wiki:
http://confluence.public.thoughtworks.org/display/CC/Home#Home-thirdparty
Jtf
Thanks Jeffrey – once I have something more concrete to release I’ll make sure I update the link…
This sounds like a really cool idea. I’ve been using CruiseControl for almost a year, and I’ve just stared implementing Trac, so tools that will tie both of them together are really interesting to me.
So … how’s it going on turning this spike into something releaseable or even a snapshot that someone else could push forward?
Cool stuff ! But so poor because i have to different servers. One i setup Trac with Mod_Python, so i can setup the stuff. But the other i use with Trac Daemon (using port 8000), so i don’t know how to setup the plugin for the server! Anyway the stuff is exciting, and the article is same
@Jeffrey Fredrick : The link (CC link on ThoughtWorks) you gave is so cool !