Whoops - sent too early

- Jenkins
  - Ugly
  - Java (I could probably stop there)
  - Crappy client (requires fairly specific versions of Java files and has flaky connection issues)
  - Bad interface for custom build scripts
  - Really made for testing Java web-apps
  - Did I mention it's ugly and hard to navigate?
  - Has some GitHub linkages - but it's definitely a bolt on
- Travis CI
  - Works great if you're developing a server-side web-app, but that's about it
  - Can't run jobs on your own boxes
  - Limited control over environment
  - Not clear how easy/hard it would be to test MPI execution
- Cloudbees
  - REALLY crappy client (modified Jenkins)
  - Have to pay through the nose to be able to run the client on your own boxes ($200/month + $5/build box to USE MY OWN DAMN MACHINES TO BUILD?!)
  - Still Jenkins
- Atlassian Bamboo
  - $800 to run _one_ build slave on my own hardware!?  Are you serious?
- Bitten
  - What we've been using for years
  - Works great, but is tied to Trac.
  - Has good handling of multiple configurations
  - No GitHub integration (can be used with Git - but can't do anything with Pull Requests)
  - Has a good client that polls using http
  - Kinda crappy XML interface for defining build recipes

I'm probably missing some that we looked at...

Here are the features of MooseBuild:

- Builds run on own hardware
- Written in python
- Uses modern technologies (Flask, SQLAlchemy, Jinja2)
- Simple client that polls using http
- Supports build pools (can have many machines that can pick up a job if it's available)
- Native support for many environment configurations
- Build recipes are just plain and simple Bash scripts
- Can have dependencies between recipes
- Built to work directly with GitHub (listens for Pull Requests, reports back to GitHub using the GH API for comments and CI status)
- No separate account (you sign in using GitHub)

Those are the highlights at least.  I was blown away that nothing like this has existed yet... even crazier is that GitHub itself should definitely have a solution like this built in (I talked to one of the GitHub guys about that at Supercomputing this year).

Anyway - it still has a ways to go but it's already pretty sweet (other than looking like ass :-).


On Fri, Feb 21, 2014 at 9:33 PM, Derek Gaston <friedmud@gmail.com> wrote:
Clients poll (simply http requests on port 80).  That was important to us for the same reason (and one of the reasons I don't like some of the other CI systems).

Not just buildbot.  Here's a list of systems we tried/looked at and their issues:

- BuildBot
  - client in constant connection with server
  - One client per thing to do (no build pool)
  - Terrible handling of multiple configurations (if you want to compile the same thing on osx, linux, linux-clang, linux-intel, etc you have to create separate builders and the output is insane with hundreds of columns)
  - No ability to build pull-requests on GitHub
- Jenkins

On Fri, Feb 21, 2014 at 7:01 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk@nasa.gov> wrote:
I've got no issues - as for the clients, does the server communicate out or wait to be polled?  I ask because I've got some client resources,  but they are behind a firewall and can't just listen on a random port...  They could periodically poll out though. 

Looks interesting!

I take it you've found buildbot lacking?

On Feb 21, 2014, at 8:02 PM, "Derek Gaston" <friedmud@gmail.com> wrote:

I'll also make it run a "make check" - I forgot to mention that part.  We can expand from there later...

On Friday, February 21, 2014, Derek Gaston <friedmud@gmail.com> wrote:

I got pissed off at all other continuous integration capabilities so I wrote my own.  It's currently hosted at moosebuild.com (you can go there, but please don't sign in yet because everything isn't finalized and I don't want you to lose anything you do on there - not too mention that all of the security stuff isn't completely turned on yet).  Yes, it is currently ugly - I just haven't put any effort into making it not ugly yet ;-)

Even though it's not finalized - it does work (I've got it hooked up to the MOOSE repo currently) and I would like to add the libMesh repo to it.

The way it works is that when you put a Pull Request in on GitHub - GitHub will send a message to moosebuild.com that creates build jobs.  Those jobs get picked up by worker clients (that can be running anywhere that can reach moosebuild.com) and then those clients run the build recipes (bash scripts that you create at moosebuild.com).  The results get reported back to GitHub using the continuous integration API's that GitHub has.

So - does anyone object to me using this to automatically test MOOSE against every pull request coming in to libMesh?  It will create a bit more chatter on the pull request (some automated comments come out of the system as well that point you to the build results) but I think it's worth it (and we can refine that chatter over time).

This is basically a first baby step toward opening up the system to a wider audience...  I want to get some feedback and refine some stuff before I do that...

Let me know what you think,

Sent from my iPhone
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
Libmesh-devel mailing list