I’ll just note before I start writing that I am pretty terrible when it comes to Linux. I’ll read a guide on how to build your own home server with a Linux distro, or how to get shiny graphics in Ubuntu, and miserably fail at around step three or four. I’m not sure why; maybe it’s because I’m a filthy casual OS X user, but I never seem to get along with ‘nix.

So the past day and a bit has been confusing as I struggled to make use of my school netbook, currently languishing in a corner doing very little, as a build machine to automate testing and building of software that I write. Enticed by the continuous integration1 build setups at work and those noted as being “best practice” at university (both of these preach continuous integration as a development methodology), I thought I’d make my own little CI server. Turns out that it’s not as easy as I expected, after attempting to install Drone CI.

Drone CI is a tool that I’m pretty sure is built by GitHub, and all the tools seemed vaguely followable till I realised that there actually two different methods of installing Drone: through a .deb file as a legacy Ubuntu app which only runs on 14.04 and below, and as a Docker ‘virtual’ application that seamlessly integrates with Docker.

But of course these semantics were not clearly explained, so I first followed the official guide, and then when that didn’t work (because of a missing dependency that I’ll explain later) I tried the legacy application before realising that it wasn’t going to work either. Sigh.

The installation of the dependencies was not clear in the official docs, which I’ve since found out are really new and fresh for their new Docker app, and I had to install Sqlite3 and some Libsass program in order to get the Docker app working. But of course this took me ages to realise, because the logging part of Docker was tailing anything newer than the first ten logs of the application, and was ignoring my attempts to get it to display the entire log. So I had no idea what was going on, why the thing wasn’t running, nor how I could fix it. And since Drone is actually pretty new, there’s not many support threads out there yet that cater to complete newbies like myself, or any docs that don’t already assume a complete understanding of Docker. Word of suggestion to the fabulous developers of Drone: don’t make your platform dependent on a program if you won’t provide full clarity around how that platform also works in tandem with your app.

My fourth and final source of confusion was how it all would pull together, or how to format the damn config file. I wasn’t sure whether to use Docker notation, environment variables or Drone’s notation for configuration, or if I even needed a config file (turns out you do). Stumbled around a little bit in it before I finally realised that I needed to link my Github account in order to get Drone tying its own shoelaces, and that this process was impossible on a local dev machine that doesn’t have an outward facing IP address or DNS address, a necessary evil to do the OAuth callback from Github’s API. Apparently no one uses local machines anymore for development; only cloud VMs.

Don’t get me wrong, the application looks promising and the developers have been nothing but pleasant as I’ve asked them questions. But like many open source projects, it struggles to document itself effectively and get someone like me up and running with the project.

What next?

  1. Continuous integration is basically the practice of constantly integrating your code branches with other developers in your team, reducing the amount of conflicts and breaking changes that go unnoticed until production.