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
------------------------------------------------------------------------------
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