We're thinking about running our own buildbot against the upstream llvm
and clang sources. I'm talking to our build folks and seeing what they
can allow. Maybe we can contribute some build slaves to the osuosl
buildbot but I'm not sure.
If we do end up having to run our own buildbot, what's the best way to
integrate that into the upstream web page and status notifier?
You can't, really. The buildmaster contains both the webpage, source
control change detection, and slave management/scheduling. If you can
have your slaves connected to that buildmaster you can integrate with
those features. If you can't, then you'd be running your own
buildmaster which would have its own status page, etc.
The "integration" at that point would probably amount to the nag
emails you see from the current buildmaster - though I'm not sure what
problems you might run into emailing from other hosts, etc (people
might miss your automated emails/dismiss them as non-authoritative,
accidentally classify them as spam, etc).
Basically, we want the buildbot to monitor the activity upstream and
look for things that break certain build configs (-Werror is one of
them), letting people know when there is a problem.
Our machine might not be able to keep up with a build for every commit
but could do regular timed builds. The blame list won't be as precise
but at least we'll all know if something goes wrong.
Minor point: Every commit or timed aren't the only options - usually
the way this works (& the way the zorg builders are setup) is that
they try to build on every commit, if commits come in while a build is
running, those will be rolled up into a build starting immediately
after the current one finishes.
Obviously the fewer commits per
Would we create a directory in zorg along the lines of the osuosl,
smooshlab, etc. directories under zorg/buildbot?
I just checkout the zorg repository & run my local buildmaster out of
that. I don't contribute this code upstream - there doesn't seem to be
much point in doing so.