There’s a little gem of a feature in Bamboo that I bet goes unnoticed by a lot of users: in-app management of all the data left behind by builds. Artifacts, logs, stats… the whole kit’ncaboodle. I love this.
“Back in my day…”
See, in my “former life”, I was a test automation engineer and we used Hudson as our CI server (this was in the pre-Jenkins era, before Oracle and Kohsuke’s relations devolved into pistols at dawn)*. We ran Hudson on a re-purposed tower unit that sat underneath my team lead’s desk, and as you can imagine, it offered finite storage space. Very finite. So every once in a while a build would fall over because there was no more room on disk to write the logs to. We had scripts to help manage this, but kept having to make them more aggressive as the archived data (even when compressed, it was still larger than zero) filled up the disk. We would’ve been happy to trash most of the logs and artifacts and keep the result stats for purposes of spotting trends, but never mustered the time or gumption to re-work our scripts accordingly.
So imagine my delight when I started using Bamboo and found a page in the Administration console called Build Expiry. “Helloooooooo, what’s this?”, said I. 30 seconds of exploration later, the chorus of angels started singing in my head. You mean I don’t have to fumble my way through writing log rotation scripts anymore? Joy! And can keep only the data types that I want to keep? Glorious! And I can make exceptions to my settings based on a build’s labels?! (At that point I was so excited, I nearly peed on the rug.)
Killer Controls for Labels and Plans
If you’ve never played around with your build expiry settings, go to Administration > Plans > Build Expiry, and you’ll see your global defaults. Click the Edit button, and you’ll see some interesting options appear. Pretty straightforward, and you can always refer to the help docs, so I won’t go into tons of detail here.
It’s the “labels to keep” thing that really gets me jazzed, though, because there are so many good uses for it.
The most obvious is that you probably want to keep everything about every build that you’ve ever deployed to production –especially if you’re in an industry like healthcare or finance and are occasionally audited to ensure compliance with various regulations. Once the build is deployed, go to its result summary page in Bamboo and click the little pencil icon next to “Labels”. Add a label called “production_deploy” (or similar), then make sure your build expiry configs include an exception for that label.
Another popular practice is to keep builds that had performance anomalies so they can be investigated. We all know the analysis usually gets added to the backlog for “later’, so configuring a label-based exception to your build expiry rules ensures that the build is still around when “later” arrives. To find the labeled build, go to ${Plan} > Plan Summary > History, and scroll through. You’ll see all the labels displayed there.
There are loads of other uses for this… keeping release candidates around for UX/PM review… flagging the build that you used in your sprint demo or client demo… But the most important use cases are the ones you’ll come up with on your own. And you can override both the build expiry and exceptions on a per-Plan basis, which makes it even more powerful.
Bamboo can automatically label builds at the Job level, but labeling builds at the Plan level is currently a manual step. A task plugin for that would make a perfect Codegeist project, don’tchya think?? C’mon gang, there’s $45K in cash prizes in it for ya! Plus hella street cred. Just sayin’.
Anyway… give this build expiry and labels stuff a try on your own. If you love it as much as I do, come back and drop a comment telling other readers the kick-ass way you put it to work in your project.
Keep on making great software, y’all!
**This was also before Hudson supported separate expiry settings for build results and artifacts, which, to be fair, is now doable in Jenkins with a plugin. But Jenkins’ in-app management still doesn’t let you separate build stats from logs like Bamboo does, and logs are the real disk hog. So yay for Bamboo.