On Wed, Dec 12, 2012 at 11:04 AM, Roy Stogner <firstname.lastname@example.org> wrote:
Nick Malaya set up something similar over here with the TACC systems -longhorn.tacc builds and tests our manufactured solution library MASA
with the Portland Group compilers, and reports the results back to our
"master" server where it gets integrated into the same waterfall, web
interface, log archiving etc. as everything else.
It doesn't look like Buildbot will want to chat over the network with
non-Buildbot slaves (Nick claims that the simplest way to do things is
to install buildbot, test it with a local master/slave configuration,
then point it to the remote master instead), but we'd *love* to be
able to see the stdout/stderr from any cases where other developers'
patches break your tests. Having to iterate back and forth between
"old PBC code with a theoretical failure case" and "new PBC code which
fails your tests" without even getting to see your tests' output
Is that going to be controlled-information-kosher, though? E.g. just
tripping an assert can spit a stack trace to stderr, which wouldn't be
enough to make me worry but might be seen as violating others' rules.
And if we might ever actually had a *malicious* developer, there's the
possibility of 'add system("find source | xargs cat") to LibMeshInit,
push to devel, go check BuildBot to see what we hooked' to worry
Ben and I (at least) haven't been getting the automatic emails thatlibMesh pull requests are supposed to generate; you might want to ping
-devel at the same time until we get that sorted out.
I'd have interpreted a pull request as an invitation for *anyone* toNow, if I submit a pull request and everyone is ok with it... I can
do my own pull into the officially libMesh git clone on my
workstation and merge to master and push on my own.
do the merge to master & push. Not a good idea?