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
