A long long time ago we used Jenkins. Then we switched to Bamboo because the Jenkins interface was feeling a bit 1990s.

So now it’s like 5 years later and we’re in the process of moving back to it. Here’s why.

It’s Free

Bamboo isn’t free. Want to host it on a server and build on that same server? $10. Want to use a single remote build server? $800. Want to use up to 5? $2,200. Want to upgrade next year? $1,100.

Money isn’t so much the deciding factor for us. If Bamboo was outright the best product, we’d pay happily. More of an issue is the fact that pretty much every atlassian product has overcomplicated year 2002 enterprise style pricing.

Jenkins is free. Open source.


It’s 2017. Updating software shouldn’t involve all this bullshit.

To update Jenkins you press a button and it updates and restarts. There’s updates every few days.


Our wiki uses Confluence (also by atlassian). It got 1000 comments on a page made by spam bots. There’s no bulk delete comments option. If you search you find multiple instances of customers with this problem. So what’s the solution? Obviously not to add that basic functionality. Let someone else add it and sell it for $10 a year. Or buy a script to run scripts for $100 a month.

Again, I’m not totally against paying for addons, but not for basic functionality. Not to clean up messes that the inadequate captcha software let happen.

Jenkins addons are free, one click install, update automatically and very very regularly.

The Interface

The one huge thing Bamboo had over Jenkins is that it didn’t look like shit. Jenkins has changed in a few ways since I last used it – which closes that gap slightly.

Ocean Blue is a plugin they made that seems to specifically solve this problem. It replaces the functional engineer view with something more simple.

It’s all modern and appy. Which makes people more appy.

It’s made in a way so that non coders can put together build steps. But that’s for idiots, so don’t worry about that.

Fuck The Interface

Wouldn’t it be cool if instead of bullshitting around creating jobs, then creating build steps in the interface, you could just drop a file in your project’s repository that told it what to do.

Wouldn’t it be even cooler if Jenkins could scan though all the repositories on your SCM for repositories with these special files, and automatically create a job for them all. Maybe it could do branches too. Maybe it could build pull requests too.

Well you just described the Jenkinsfile.

Github Integration

If you use Github you’re gonna love it. Add a Jenkinsfile, it adds a project. It automatically registers hooks with Github so it gets notified on pushes.

For each commit it’ll do a build and report the status back to Github. Which’ll then do little ticks or crosses next to the commits.

It’ll also test pull requests and report the status back – so you know if they’re actually going to compile and pass tests before you bother with them.


Like pretty much everything like this, the PlasticSCM plugin for Jenkins is as basic as you can get. It works to do the basic stuff, move outside of that and you’re probably gonna hit bugs. It’s something they may improve over time, but at the moment it’s got a few issues.

  • No organisation scanning like Github – all manual set up
  • SCM polling is temperamental, manually set up web triggers
  • Interface errors (set pipeline to use script from plasticscm then save, you get this)
  • No lightweight checkout, jenkins host has to pull the entire repo down to read single file

Like most people, if GitHub handled 20GB repositories better we’d have probably already moved everything to it already. PlasticSCM’s strategy seems to be to create a wrapper so Plastic acts like Git – allowing everyone to use the good plugins. That’s a neat idea, but I’ve always felt that 90% of Git’s adoption is down to how great GitHub is, so unless they can wrap Plastic in Github I don’t see much advancement here.

So with PlasticSCM you can limp along, manually adding jobs and it works. And I assume that’s the case with every other SCM.

6 thoughts on “Jenkins

    1. Yeah,not for a while, but when it first came out. It seemed quite slow. Googling it at the time put the blame on Windows, and suggested a bunch of commands to speed it up. It might be time for another test.

  1. I’m currently managing a pair of Jenkins instances for the university where I work, and it’s certainly nicely packed with most features you could possibly want. Once you get into an environment that’s outside of the norm though, then things start becoming tiresome.

    I think I’m up to 8k~ lines of Workflow lib code now to do things like templated builds, package staging/publishing, metadata generation, comment creation with validation fixes, test case discovery, and more.

    Of course, we’re using a self-hosted GitLab instance instead of GitHub, so there’s a few things we can’t do as easily in Jenkins which means more code on our side being needed.

      1. We could probably get GitLab CI into a state where it’d do most of what we need, though it would probably take much more work from our side, and it would make it much harder for us to do certain things.

        Currently, we’re running pipelines to validate changes to our Puppet code, which needs to be done because anything that gets in there has a chance to break our entire production environment otherwise. And due to legacy reasons we have over 250 puppet modules that need this validation.
        We have tagged versions of our validation tools that need to run – and need to be updated from time to time, there’s a total of eight different validation steps that always run, between one to four additional validation steps for a few of the modules, rspec is not yet in place for every module, and we have one developer who refuses to use the correct indentation style.
        Having to keep that many CI definition files up to date would be hell, especially when – with Jenkins – I can remove that entire element from the problem.

        Here’s the entire Jenkinsfile for our monitoring Puppet module, as an example:

        #!/usr/bin/env groovy
        puppetModule {
        // Technically this could be skipped, it’ll fall back to the repository name
        name = ‘monitoring’

        Which will equate to something like;

        stage(‘Validation’) {
        parallel puppetLintRC: { /* … */ },
        utf8BOM: { /* … */ },
        puppetLint: { /* … */ },
        puppetParser: { /* … */ },
        eppValidate: { /* … */ },
        erbValidate: { /* … */ },
        rubyValidate: { /* … */ },
        metadataLint: { /* … */ }

        // If rspec tests are available
        stage(‘Test’) {
        node(‘ruby’) {
        // …

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s