So, my last post ended with the statement that ‘having a non-breaking build is a wonderful thing’.  Too bad it wasn’t quite that easy…

After verifying that my Dockerfile ran in my boot2docker environment, I merrily checked in my changes to the base build, pressed ‘Build’ on Jenkins, and waited for the build success message to appear in our team chat room.  No luck – build failed.

OK, it turns out that our build is actually controlled by a bash script which calls fig and docker.  No worries – will just test it out in boot2docker, as I really don’t like build break messages coming over the wire.  Here’s where the problems started…

1. First step: do the fig commands in our build.sh work in boot2docker?

boot2docker for OSX comes prebuilt with fig.  boot2docker for Windows doesn’t, at least as of issue 603, which is still open for boot2docker 1.5.  fig is now Docker compose, and I found a cheat to add an alias for fig which under the covers makes use of a Docker container for fig.

2 . Second step: run the build.sh itself..

It turns out that ./build.sh doesn’t work in boot2docker.  That’s because boot2docker’s underlying Linux distribution, Tiny Core, doesn’t have bash installed.  Turns out to be solveable using tce-load, ala ‘tce-load -wi bash.tcz’

3. OK, now why does the build.sh still not work?

I have fig aliased and it’ll run from the command-line (fig up works…), bash now is available, so why am I still getting told it can’t recognize ‘fig’?  Turns out that the alias won’t work within the script itself and I needed to hack the script to source my .bash_aliases.  Bleah.

4. It works on my box!

The container builds, it starts up, and my simple curl test works well, after replacing localhost with the result of boot2docker ip to get my VM’s IP address.  Docker and fig exist to make things work very portably, so I check in and…  all’s not well.  More for part tres.