• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Bare bones continuous integration



Thanks: 10
Messages: 22

I've given some thought to throwing together my own bare CI tool using shell scripts and jails (and optionally zfs). The flow would be ...

1. check git / svn for new code changes (crontab).
2. create a new jail.
3. install any dependencies (in a jail).
4. git clone (or svn checkout or cvs co or bitbucket/bitkeeper, etc.) (in a jail)
5. make (or gmake or cmake or whatever - in a jail).
6. make install (in a jail).
7. run unit tests (in a jail).
8. save results - outside the jail eg. email or log file.
9. destroy jail.

Step 3 could be sped-up by using a jail template or re-using the jail from a previous run. Steps 5 and 6 are the main reason for using jails.

It seems to me to not be that difficult. iocage or ezjails simplifies the jails part. The overall learning curve would be less than Jenkins / Travis / Hudson / Bamboo. Since I created it, I'd likely know how to fix it when it broke. This also appeals to me because it does not require Java (or a Linux VM in the case of Bamboo) as a hard dependency.

You could go feature crazy (like incorporate iohyve or chyves to cover other OSs) but my aim here is to do something small and simple.

I've got too many other toy projects at the moment but this is on my "TODO" list. If anyone has already done this, please speak up!



Thanks: 19
Messages: 34

I've actually been fiddling around with a very similar concept, not for continuous integration per se, but I have automated the creation, execution and destruction of jails in a manner that would be very conducive to CI if that were the desired use case. I may publish my source once I make it a little more general purpose and decouple it from some proprietary stuff, but PM me if you want to talk more about my specific project and implementation.

You can also run integration tests against an app running in the jail since an app running in the jail can bind to ports on the jails IP address.

With regards to speeding up "step three", ezjail provides a very convenient way around this. You just add whichever dependencies you need to an ezjail "flavor", and they will be available, as configured, in any jail you create of that flavor.

In any case, its totally feasible and I can say I have (mostly) done it