Jenkins: Butler Messmaker
Jenkins: Butler Messmaker
Join the DZone community and get the full member experience.Join For Free
Delivering modern software? Atomist automates your software delivery experience.
I have been reading the Manning book SBT in Action lately. When I first came across SBT a couple years ago, I saw things like the && syntax and wanted to vomit. However, after using it now in a bunch of places, it‘s clearly superior to Maven, and making a new tool was not at all an act of hubris on Typesafe‘s part. One of the main reasons, which might not be immediately apparent, is because SBT really covers the whole lifecycle for you: when you build your Akka or Play app, SBT takes it all the way to running in a server. Think about that for a minute. Are you slapping your forehead?
Last night I got some messages that the main drive on my mac mini server had filled up. Got on and ran DaisyDisk. Found that Jenkins had done its usually thing of leaving a bazillion built artifacts around. Seriously over the years of having Jenkins do deploys for me, I have spent many many hours (many too many) cleaning up the stinking mess. I know I did a post about it on here once in which I said the first law of computing should be ‘thou shalt not make a mess.‘ To me surprise (not), I found that though many people have asked for this, it is still not in the app. I found the offending job. It was a deploy job that was simply depositing a war on a dev instance. Of course, deleting the left over wars was a huge hassle. DaisyDisk could not do it. Eventually I did get them deleted. The other little piece here is that if you go in and tell Jenkins that you want it to hold on to only the last 3 builds, do you think it would be smart enough to go and delete the older ones? Yeah, no.
Here are the range of ways this should have been dealt with:
- make the default to only hang on to a small range of jobs
- have a special kind of job just for doing deploys and again, have it default to holding onto a small number
- have a way to configure an old artifacts repository in a separate location: my mini has an SSD and a spindle (btw, this experience was a good ad for a fusion drive)
- have a simple way to just show the old artifacts in the job window and choose to delete them from there
- have templates for jobs so I can say that certain jobs should only retain infinite builds
- if I push the artifact into my repository, then there‘s no reason to retain it in Jenkins, but Jenkins was not designed to work in conjunction with the repository, because, after all in the age of Choice is King, it would be fascist for Jenkins to assume you were using Maven or Ivy
Remember at the end of the RUP Era, when Agile was just getting rolling, one of the main talking points was that in waterfall, there are too many handoffs between groups as phases are done serially and with each group speaking its own language. That‘s what we have now in the tools world, which is one of the main reasons that tools like Xcode and IntelliJ are looking so appealing these days. Hobbling together all the different parts and trying to get them to all harmonize with each other is complete and utter madness.
Oh, and SBT has another thing I didn‘t know it had that is really pretty exciting and useful: an interpreter. I haven‘t looked at WTP 3.5 yet, but needless to say, the process of making it easy to seamlessly build and deploy has been a rocky one (in the decade since its founding). ‘Here, I will build your thing for you, but if you want to run it, good luck with that…‘ ‘Thanks!‘
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.