The Goldfish Chronicles

http://www.openartist.net/?p=12

Very slick, sucks that we didn’t notice this in 2005.

This, I suspect, will take a while. I need to choose a CI system to use and the list to choose from is large. It’s for open source, so commercial products that give open source projects a free license are in the list. However I do feel that if one of the open source versions can do the job, the commercial ones should not be chosen.

I have some experience with CI - I’ve written my own in Perl (hey, it wasn’t that bad!), used Continuum 1.0.x and used CruiseControl. I quite like the latter, but I want something a bit more visual and as most of the projects being built will be Maven2 based, I want it to be easy to do Maven2 while also still allowing
a C++Make project to build (for example). I doubt the latter will be an issue, but there might be good Maven2 support in a CI. One feature I lust after is being able to choose the JVM to use when building, so that’ll be a big plus.

Here’s the list, with my thoughts and assumptions on their website - I’m sure much of that will be wrong. I’ll followup with more in-depth thoughts as I dig in.

• TeamCity
• Pulse
• ParaBuild
• Hudson
• CruiseControl
• Continuum 1.1
• Bamboo
• Anthill Pro

TeamCity is found at http://www.jetbrains.com/teamcity/. The first feature they push is their “unique delayed commit” feature. It doesn’t seem very interesting to me, and as it blahs about IDEs, my assumption is that it won’t be much use to me in ‘vi’ and ’svn’. Next they talk about their “innovative Build Grid”, but that’s not a feature I need - this is a one machine gig. The third feature is that they do “code quality analysis”. Again, not a feature I want - developers can do this themselves. All in all, TeamCity seems to be well named - good features for a team.

Pulse is found at http://zutubi.com/products/pulse/. Lots of build types supported, multiple machines (don’t care), personal builds (hmmm.. much like TeamCity’s unique delayed commit ), extract information using regexps (they know how to sell to me it seems), scheduling, reporting, graphs, blah blah but sounds good. I must admit, I tried a few of these a couple of months back and Pulse was at the top of the list, so expect to see more on that as I dig into the ones I hadn’t looked at then.

ParaBuild is found at http://www.viewtier.com/products/parabuild/. I hadn’t even put it in my list as I thought it was commercial only, but a link on Google AdWords to ‘viewtier’ when searching for Pulse made me check their site and lo and behold, they offer licenses to open source projects. Of course, they say ‘High visibility open source projects’, so I doubt I’d qualify :). Still… features. Firstly… their favicon.ico is a bright cyan square. Not a good sign of quality eh? It’s a surprise that arguably the big name in the field have such a basic site. I know it doesn’t mean much, but it’s also worrying to see the site’s copyright as 2006. The first feature to jump out is, oddly enough, Fisheye integration. That’s a plus as I’ve decided to run Fisheye. They provide a simple list of features - the usual suspects - but I’m left feeling that there’s not a lot of information on the site. Generally my experience here is that ParaBuild is in the ’second division’ so to speak along with TeamCity for my investigation. Harsh, but with so many to choose from it’s often the little things. Google did find a hosted version for open source projects, which helps me get a feel for things. I feel an urge to find a nice machine and set it up building Commons Lang under all of these tools. The ParaBuild dashboard is bizarre. Lots of green boxes! Woo! And?

Hudson is to be found at https://hudson.dev.java.net/. It’s the first open source project in our list, and has a nice site over at java.net. It seems to mostly just be the work of Kohsuke Kawaguchi, so one part of evaluating it will be to check the svn to see if anyone helps. DamageControl was a promising one a while back with a single developer that seemed to lose momentum. It has a JIRA plugin, but sadly it’s not a JIRA plugin as I would expect. My JIRA plugin would be such that when a build fails, it opens a JIRA issue. The Hudson one is such that users can go from a JIRA issue to the first build that contained that issue. Bit worrying in that that seems to imply that it keeps lots of builds around. Disk space ain’t free yet. Most of the site is hosted at http://hudson.gotdns.com, which seems to be a bad Confluence export. Doesn’t say much for java.net if people prefer to host from home. Hudson talks about plugins, which is good. I want to be able to do plugins because that makes things fun. One thing I don’t like is the ‘advantage’ of “No more “full rebuild” before a commit”. No no no no. Tools don’t exist to make sloppy developers, they exist to enhance good developers. Hudson also subscribes to the philosophy of having the CI tag the source when it builds. Ack. Basically I’m not in favour of building your development around the CI. Generally Hudson has the desired features, I just need to get over some of my grumbles above.

CruiseControl is found at http://cruisecontrol.sourceforge.net/. While I like CruiseControl because I think the polished GUI should sit on top of a solid command line CI and not be the CI; CruiseControl also lacks a polished GUI. At least I thought so. Digging around their site, I find the Dashboard which seems to be just what I’d want. So CC has leapt from second division up to the first division of contenders. One of the things I liked with CC was setting up templates so a project could be added in a line of xml. A big question will be how well that links with the Dashboard which appears to have an Add Project feature.

Next up, Continuum 1.1. We’ve been using Continuum 1.0.2 at work because it was the simplest for me to setup at the time (Hudson was new at the time, CruiseControl was quiet). However, Continuum 1.1 is still an alpha at the moment (alpha-2 was released this month), the feature list doesn’t mention plugins and Continuum 1.0.2 while easy to manage and setup, has also been a pain in the arse from time to time. So - Continuum’s off to the second tier on the investigate list.

Penultimately, Bamboo - found at http://www.atlassian.com/software/bamboo/. There’s been a lot of noise about Bamboo - and I liked it when I gave it a test run a few months back. I’m not sure how useful a lot of the features it mentions will be, but I do want to check out the JIRA integration a bit more, and because I’ve enjoyed creating JIRA plugins I’m interested in the Bamboo plugins.

Lastly, in our reverse alphabetical journey, is Anthill Pro. Geronimo use this for their TCK testing and their build guy is extremely happy with it - apparently it’s very good at doing parallel multi-machine builds. That’s not a feature for my current thinking, but as with Bamboo, I’d like to play with Anthill a bit more to see what it’s about. I think I heard that it’s a bit more of a learning curve than others, so that might stop me looking at it.

So, after all that, here’s how the next phase is looking:

Try them out tier

• Pulse
• Hudson
• CruiseControl w/ Dashboard

Look into more tier

• Bamboo
• Anthill Pro

Not doing it for me tier

• TeamCity
• ParaBuild
• Continuum

A few weeks back while Carrie’s mother was here I cooked a Sunday roast. Roast pork, roast potatoes, Yorkshire pudding, peas, bread sauce, apple sauce and my experimental gravy which left gravy behind a while back and is more of a mustard sauce now. Here’s the view of the oven when I opened it and realized that the Yorkshire pudding was heading skyward.

If you’re using Ruby 1.8.6, try the following:

irb
require 'rexml/document'
REXML::Document.new("<foo x='&amp;'/>").to_s

In 1.8.5 I get an answer of "<foo x='&amp;'/>", in 1.8.6 it is "<foo x='&amp;amp;'/>, ie) entities are doubly escaped when they shouldn’t be.

Released yesterday thanks to the nudgings of a user - the 1.0.2 of my ProjectList for JIRA. You can see it at work on the Apache JIRA (who are using a snapshot version between 1.0.1 and 1.0.2 currently). It provides the lists of projects in a more succinct way than the default JIRA portlets can do.

This release sorted categories and took care of errors when there were no project or category descriptions.

Thanks to the nudgings of a user, I’ve released Simple-JNDI 0.11.2. It contains a few changes:

• Maven2 build added
• Removed debug from SJDataSource
• Updated to latest dbcp/pool

Simple-JNDI is an in-memory implementation of JNDI, useful for unit tests and also as a configuration system behind gj-config.

There were a couple of comments on my JIRA migration summary. One was that there is a CSV import. I’ve only used this the once, and from the bug reports on its page it does seem to cover comments in some way or other. I’m not sure how you get the CSV though - JIRA’s issue navigator page has an Excel option but that seems to return a HTML (read Office ‘XML’) version. Not something I want to be trying to parse and munge back into CSV. Also, the Excel option does not include the comments.

The other suggestion was to use SOAP. Personally I’m far more a fan of an XMLRPC style API than a SOAP style API, so I tend to avoid SOAP APIs. Mostly when in Java - SOAP in Python was very nice when doing the Commons Bugzilla->JIRA migration. It would have taken more time than the quick RSS restyling to Jelly I was doing, and I doubt it would have helped much beyond being able to create fuller versions with release dates and descriptions.

It would be useful for one of the flaws of the mig4jira script. Currently it doesn’t handle multiple components, affects versions or fix versions. I very rarely ever set multiples, so was pretty confident my data didn’t need me to deal with those. Originally I would have considered Jelly the better choice as it’s a lowest common denominator and makes for a more decoupled process; however Jelly is now deactivated by default in JIRA and you have to modify catalina.sh and restart to turn it on.

I’ve needed to move some JIRA issues from one issue tracker to another. There are a few options available currently for this, and I’ll explain why each one doesn’t work before mentioning how I’ve solved this.

• The simplest is to copy them by hand. There are too many for me to want to do that, and you can’t set some of the data.
• Another simple one (in terms of design) is to write some sql scripts. This is a notoriously painful thing in JIRA so I avoided that.
• One option is to backup the JIRA, bring the new one up on top of the backup and delete the bits you don’t want. This obviously fails if you want to move to an existing JIRA, and it’s a pain if you only want a small 0.1% of an existing JIRA. Plus the paranoid in me would not trust that the deleted issues are really gone.
• A recent option is to move the issues one at a time from JIRA to JIRA using the Fedex V - Move Issues project from Atlassian. Sadly it’s not released, I suspect it’s something we’ll see in JIRA someday rather than as a plugin, and it’s limited currently to an issue at a time.
• The last option is to use the Swizzle Jira Report jira-to-jira ‘report’. It takes a public JIRA and xmlrpc connection and generates Jelly to migrate a project. There-in are its limitations currently; your JIRA needs to be public and it migrates projects.

My requirements are to migrate from a private JIRA to a public JIRA, and to migrate specific components from a project and not a project.

Here’s my solution. Okay, here’s my hack. It’s inspired by the Swizzle jira-to-jira.vm. I take an RSS file and run a pair of xsl’s over it to get two Jelly scripts. The first one creates necessary versions and components. It’ll warn when you run it in the JIRA as it doesn’t try to enforce uniqueness, but it’s not an error. The second creates the issues. It dies on error (and you have to delete the ones already imported and try again). Typical errors were a non-existent user and a non-existent resolution.

Here’s the script - I call it mig4jira. I still had to go in manually and release the JIRA versions, but otherwise it worked very nicely.

Ideally the ultimate solution will be to change Swizzle to support private JIRAs and to write a jira-to-jira script that works off of a user specified RSS script.

• The Manage Entries page has a happy text search (I wrote that for Roller!), but it doesn’t tell you how many entries came back. The ‘Previous Entries’ bit seems to fail on that page too.
• Drafts are poorly managed, just a big long horizontal list of urls. If you’ve a lot of drafts, that’s irritating.

This is an odd one. My blog’s inline <img> tags lost their src attributes; however Carrie’s don’t seem to have done that. Very odd. So I’ll need to search for ‘img’ and see if I can fix the data. Apologies if that republishes things in the RSS.

Fortunately I don’t inline images often (while Carrie does a lot). Another migration woe that I fixed by hand was that my drafts were automatically published.