Working with Jenkinsfiles in VIM

Using Jenkinsfiles in repositories for declarative pipelines, which is an example as infrastructure as code, is absolutely the right thing to do, in my opinion.

However the tooling for debugging and error checking Jenkinsfiles is currently quite difficult.

Setup Jenkinsfile linter

First of all you need to make sure to be able to access the Jenkinsfile linter. This linter is processed on the Jenkins server itself, unusually. There is a configuration option that requires adminstrator access to the Jenkins server.

There are a number of options to access the linter, but Jenkins officially recommends the ssh server option with preshared ssh public keys as outlined here:

Once you have set it up, you can pipe Jenkinsfiles through ssh to the linter and it will lint the Jenkinsfile for you:

ssh -p1337 declarative-linter < Jenkinsfile

(change and the port number to match your configuration of course)

And it will output the errors in the file.

Jenkinsfile syntax highlighting in VIM

VIM won’t automatically syntax highlight Jenkinsfiles because they don’t have an extension that it recognises. This is easily fixed with the following autocommand added to your .vimrc though:

autocmd BufRead,BufNewFile Jenkinsfile set filetype=groovy

This will ensure that Jenkinsfiles have some measure of syntax highlighting when loaded, as they are valid Groovy files.

Jenkinsfile linting on save in VIM

Once you have the linter running on a ssh port (see above) you can add this line to your .vimrc to have the linter run whenever a Jenkinsfile is saved, allowing you to debug your changes when you save them:

autocmd BufWritePost Jenkinsfile !ssh -p1337 declarative-linter < %

(change and the port number to match your configuration of course)

This setup should make it significantly easier to spot and fix errors in your Jenkinsfile before it gets to the git commit stage.

My Favourite OSX Apps for Development

I’ve just recently bought a Macbook Pro for myself, after having used a MBP at work for 4 years. I find it to be a really powerful development environment for the development I do, in languages such as Java, PHP, Ruby, Python and JS. Here is what I use day-to-day:

OSX El Capitan

I haven’t found anything not to like about this upgrade. I don’t use a lot of external devices, for which Bruce has found problems with El Capitan’s new restricted driver management for Arduinos and others. I like the fact I can use split screen functionality to side-by-side two windows easily, a feature that I very much like in Windows 10 too.

iTerm 2

This is an awesome terminal, better than OSX’s terminal. Nothing much more to say about it.

Fish Shell

This shell has fast and smart command-line completion which is very handy and I’d highly recommend it if you use the commandline a lot and are not totally won over by Bash. It looks nice too.


This is pretty much essential for command line OSX. It is a package manager which downloads and compiles the latest version of open source packages on your Mac. If you don’t use it already, get used to it.

IntelliJ WebStorm

WebStorm is great for debugging JavaScript applications, which I seem to be doing a lot of lately. I recommend the IntelliJ IDEA family of IDEs, once you get use to them, they are a great help in productive development. There are also vim and Emacs keybindings.


If you are a fan of vim you will know what I mean when I say I can’t be without it. My Dotfiles show my .vimrc and plugin configuration.


Thankfully the BBC has moved over to Github, meaning all my coding uses Git. It is so useful, and not just for storing code, you can store anything.


I use Apple Music, and iTunes Match, so iTunes is a must. It annoys me at times, but I just have to live with it.


Alfred is a replacement for Spotlight search in OSX. It has a lot of functionality that I’m still getting my head around, but it speeds up my OSX workflow a lot when undertaking frequent tasks such as Google searching.


Evernote is so useful for making and sharing notes on my phone, mac, work computer.. anywhere


This is something someone only recently recommended to me. It seems very useful from what I’ve seen, great way to share images files, screenshots, webcasts.. anything. Also it has as expiry policy for media, like Snapchat, so it doesn’t exist on the internet for generations to come.

256 Color VIM on Crunchbang Waldorf

256 Colours in VIMTo get 256 colors working within terminator in Crunchbang Waldorf, I had to do the following:

  1. Add to ~/.bashrc
    export TERM=xterm-256color
  2. Install a 256 color VIM colorcheme, see desert256 for example.
  3. Add the following to ~/.vimrc:
    set t_Co=256
    set t_AB=^[[48;5;%dm
    set t_AF=^[[38;5;%dm

    ‘t_Co’ specifies exactly how many colours VIM can use. The other two lines seem to be Debian-specific color code escape sequences.

  4. If you want 256 color VIM for your root user when you sudo edit, then edit /usr/share/vim/vimrc and copy across your settings from your local ~/.vimrc and ~/.vim to this global environment.

My minimal VIM config

This is the absolute minimum I do when I have to log onto a new server or shell account that I haven’t used before, that I will need to edit text files with.

First I figure out whether VIM is really installed. A lot of installs, especially those based on ubuntu, ship with VI aliased to VIM, but the VIM install is usually not really VIM at all, and behaves exactly like VI but with some minor bugs fixed. This is not what I want.

So first I figure out what distribution of linux I’m using through executing the following command:

cat /etc/issue

Then if it’s ubuntu, which doesn’t ship with the full VIM package on a lot of default installs, then I usually do this, presuming I have admin access. In practice I usually have admin access because people are generous with this when they want you to fix their server =) Anyway, if I have admin access, I install ubuntu’s ‘vim full’ package, which is aliased as ‘vim’:

sudo apt-get install vim

Now I can move onto my config. Occasionally there will be a global system config, but I probably want to override that anyway. So I create a vim configuration file specific to me in my home directory:

set bg=dark
set backspace=2

The first line sets the background to be dark, so I can see what is going on when I use a dark terminal program, such as putty, mac osx’s terminal.. in fact nearly all terminal programs use a dark background, so this setting is almost compulsory.

The second line configures the behaviour of the backspace key, so when I go the the start of a line, and press backspace, it adopts the wordprocessor conventional behaviour of skipping to the above line. Otherwise it uses the default VI behaviour, which is probably not intuitive at all to anyone who didn’t grow up on UNIX mainframes and such.

The very existence of a user-supplied configuration file will also jolt the VIM editor into ‘non compatible mode’, where it figures out automatically that it should be doing all the advanced VIM things, instead of just acting as a VI replacement. This should mean that if you create a config file, syntax highlighting is already turned on, another must for me. Otherwise you can explicitly set it with the line ‘syntax on’, but I never have to do this anymore.

And that’s it.

Eclipse 3.4.2 + Pydev + Eclim = win

So, after saying all that stuff about how vimplugin and EasyEclipse was great, I actually started to use the setup heavily, and it started to annoy me.

For one, EE is not a recent build of eclipse, nor does it come with a full set of recent plugins. This makes it annoyingly difficult to use when you want to use more than the set of plugins it packages for you. As far as vimplugin goes, it does not provide the vim integration I thought it might from embedded vim. Not really even close.

What I use now, after lots of trial and error, and at least 4 reinstalls of Eclipse, is a combination of Eclipse 3.4.2, Eclim, (which is the most mature of the free vi-binding plugins around, and actually includes an improved version of the vimplugin previously mentioned), and the latest pydev, Mylyn and Subeclipse.

I’m using it now to refactor a largeish python project, and I’m really appreciating the help it gives me. Definitely worth trying an Eclipse setup similar to this if you’re writing any python apps that are more than small-scale.