Ben,
Maybe I wasn't clear.
What Cloudbees is, is just a Jenkins server. Think of it as a Buildbot
server. We still run the "slaves" on our own machines (behind our
firewall) but the results are reported back to the Jenkins instance.
So the tests are _not_ run "in the cloud" (that is something that is
offered by Cloudbees but we don't have to use that capability). They are
run by us on our hardware with our configurations.
I'm still not sure it's the right way to go... I just don't like Jenkins.
It just doesn't work very well (the slaves in particular are just
finicky... and all written in Java with a lot of dependence on exactly
_which_ java you run them with).
Here's what I'm leaning towards for libMesh: Repo hosting/Wiki/ticketing on
GitHub. Buildbot (or whatever kind of CI you want) hosting on our own
server that we pay for (just get some private hosting somewhere... I'll
chip in for the monthly charges and I'm sure others will too). Then we
just run the slaves on our local machines.
This gives us the most control over the process while still reusing most of
GitHub.
I'm still waffling about what to do with MOOSE. I would love for it to be
on GitHub.... but I LOVE our Trac/Bitten setup here. It just works so damn
well (we have the whole thing customized up the wazoo).
I don't really see a great way for MOOSE to be on GitHub AND use Trac....
although I'm sure it's possible.
It's crazy that the path is so unclear. I thought there would be a clear
winners here. If GitHub had it's own CI stuff built in (where you run the
slaves on your own boxes but they report back to the page on GitHub) then
we would be golden....
Derek
On Sun, Oct 7, 2012 at 11:37 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> I've been thinking about this a lot, and while it would be awesome to have
> all the CI stuff running on the cloud for free, it seems pretty limiting at
> this point because it locks us in to a single system configuration too
> much..
>
> At NASA/JSC we just got (2x) 64 processor dedicated boxes for CI, and I've
> got one running buildbot and testing everything in our "Aerolab"
> development
> environment. My intent is to take the other (when it is delivered) and
> have
> it run a bunch of virtual machines, with stock installs of SuSE, Ubuntu,
> Centos 5, Centos 6, and probably even OpenSolaris. Basically just to do
> continuous integration on standard distros.
>
> The problem is all of this is hosted behind NASA firewalls, and I'm sure
> it's a similar situation with your Bitten instances?
>
> I'm thinking a good alternative will be to " | tee " off stdout/stderr from
> my buildbot slaves, perhaps PECOS could do the same, and INL as well?
> Then,
> at the end of a build cycle, the output is committed and uploaded to a
> publicly available svn or git server where it is integrated to a status
> webpage.
>
> If we can devise some standard directory layout this could be pretty
> straightforward, and has some benefits. Basically anyone with write access
> and spare compute cycles could run a regression instance in their own
> environment, increasing the chances regressions will be caught quickly.
>
> Thoughts?
>
> -Ben
>
>
>
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
