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 :-).
Derek
On Fri, Feb 21, 2014 at 9:33 PM, Derek Gaston <fried...@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.k...@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" <fried...@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 <fried...@gmail.com> wrote:
>>
>>> All,
>>>
>>> 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,
>>> Derek
>>>
>>
>>
>> --
>> 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.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>>
>> _______________________________________________
>> Libmesh-devel mailing list
>> Libmesh-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>
>>
>
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
