Travis-CI Does Not Work When You Package Vagrant Boxes As A Build Step (Yet)
I'm learning how to use Salt Stack so I started a new project that provisions a baseline Vagrant Box for Python development.
The Goal
I wanted to check that my vagrant box can be provisioned & packaged every single time for every single change I committed into the repository so I created a .travis.yml configuration file in order to do so.
What is Travis-Ci
If you are not familiar with Travis CI then you should be. Travis CI is the most popular Continuous Integration service for Github repositories and for a good reason: It's Free and Awesome™.
Please consider using it for your current and future open source projects. It's really easy.
Before you continue go read a little bit about the .travis.yml configuration file format if you haven't done so already. I'll wait.
Done? Great, let's proceed.
The Build Process
I configured Travis to execute the following build process and thought it should work as is.
I was wrong. So very wrong. As you will see it's not trivial to implement at all.
The Problem
Travis CI uses OpenVZ virtualized containers to execute your build process. Vagrant uses a virtualization provider like VirtualBox in order to provision & package a box.
The result is that you have a virtualized container inside a virtualized container which is akin to placing a hamster wheel on top of another hamster wheel with both hamsters running in the opposite directions.
A very surprised hamster
Even the OpenVZ twitter account maintainer says it's generally considered as a bad idea:
But not being able to assure that you can release your Vagrant box at any given time defies the whole purpose of Continuous integration. So we run into a deadlock here.
Bad Ideas can Still Lead to Working Solutions Right?
Not in this case. You see, OpenVZ containers have a custom made kernel based on version 2.6.32. VirtualBox requires the running kernel to be a standard kernel in order to be able to host the Vagrant boxes. If a standard kernel does not exist VirtualBox won't be able to use the current machine as a host for anything.
Here's the build log. Go through it. If you can find a solution please leave a comment.
Master Hamster to the rescue
Possible Workarounds
- As @_OpenVZ_ sugguested above, rent a dedicated server. After you installed VirtualBox & Vagrant develop a Fabric tasks that connects to that server through SSH, executes vagrant up and vagrant package mybox. If the any of these tasks return a non-zero status code the build will fail. This solution certainly works but it is also very expensive to implement when you are developing a small open source project with no financial support. When you log in through SSH make sure your credentials are being passed over using secured environment variables.
- Attempt to build VirtualBox for the OpenVZ customized kernel. I haven't tried yet but I have little hopes that it will work.
- Wait until the awesome infrastructure team at Travis will find a solution. I will make sure to report when they will find one. Follow the Storify below for updates.