similar to: [LLVMdev] buildbot down?

On Mon, Nov 3, 2008 at 2:43 AM, Duncan Sands <duncan.sands at math.u-psud.fr> wrote: > Hi Daniel, > >> I set up a buildbot for llvm at http://google1.osuosl.org:8011/waterfall >> It builds every single revision of llvm, runs the testsuite, and >> reports the results. It takes about 3 minutes per build+test right >> now (it's an 8 core machine). > >

No :) I'm trying to start by having something that keeps people from breaking the build and tests (by letting them submit patches and being whiny 3 minutes after something breaks). Once that is done, we can move to something that keeps all the languages in good shape. I think if i simply made it do everything at once, people would just ignore it. At least, that's my experience :)

I set up a buildbot for llvm at http://google1.osuosl.org:8011/waterfall It builds every single revision of llvm, runs the testsuite, and reports the results. It takes about 3 minutes per build+test right now (it's an 8 core machine). Currently i have it building x86_64-linux. Setting up a builder/slave for any platform would be trivial. I simply don't have machines running anything but

Hi Daniel, > I set up a buildbot for llvm at http://google1.osuosl.org:8011/waterfall > It builds every single revision of llvm, runs the testsuite, and > reports the results. It takes about 3 minutes per build+test right > now (it's an 8 core machine). how does it report the results? Can it email the mailing list if the build fails for example? Ciao, Duncan.

Thanks. But please send the build notifications to llvm-testresults at cs.uiuc.edu instead. Evan On Nov 3, 2008, at 10:32 AM, Daniel Berlin wrote: > On Mon, Nov 3, 2008 at 2:43 AM, Duncan Sands > <duncan.sands at math.u-psud.fr> wrote: >> Hi Daniel, >> >>> I set up a buildbot for llvm at http://google1.osuosl.org:8011/waterfall >>> It builds every

That's cool. And I agree that it if didn't work, people would ignore it. :-) At the moment, we have only Duncan and a couple of Fortran guys to tell us when an Apple merge has broken something. I'm sure that they would welcome an early detection system. :-) -bw On Mon, Nov 3, 2008 at 1:40 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > No :) > > I'm trying to

How would I go about registering a machine with the LLVM buildbot as a build slave? I now have a fairly stable linux-x86_64 machine to add to the pool. -Dave

How do we register buildslaves with the llvm buildbot? We run buildbot internally for clang/llvm. We would like to register our buildslaves with the official llvm buildbot. reed

> I don't believe so - I think only a certain sliding window of logs are > kept (& I don't know of an easy way to view a particular revision > across the bots either) For me a bigger issue has been inability to see a long list of results for a particular builder (say, arm-cortex-a9-blah). Unfortunately while I can see "the last 20 builds over all targets" I can only

Not sure if that's related, but we had two failures last night as well: MacOS/Universal build failed on rev 54197, when building the x86->ppc cross: cc1: warnings being treated as errors /Users/julien/buildbot/llvm/gcc-build/src/gcc/cp/pt.c:5296: warning: no previous prototype for 'outermost_tinst_level' make[2]: *** [cp/pt.o] Error 1 MingW failed on rev 54208:

On Sat, Aug 29, 2009 at 4:15 AM, Duncan Sands<baldrick at free.fr> wrote: > Hi Bill, > >> ... Still, people would break the builds and let >> things go for hours or days at a time. > > don't forget the time-zone effect.  I regularly get build > failures in the morning, presumably because someone in the > US committed just before going to bed.  I guess they

On 3 January 2013 21:53, David Blaikie <dblaikie at gmail.com> wrote: > That's how you achieve this goal. What a buildbot does is governed by > the configuration in the zorg repository (that's where we keep the > buildbot configuration code that is sync'd up to the lab.llvm.org > buildmaster). > Hi David, I had a go at Zorg after the website was back online. As

Should "lit :: shtest-format.py" (from check-lit) be marked unsupported on PS4? It seems flakey there. This evening, it failed on my commit, r337514, and I'm fairly confident it wasn't my commit's fault. Then it recovered on the next commit. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/33502

On 12 November 2012 04:18, David Blaikie <dblaikie at gmail.com> wrote: >> * Can I look up results for r167602 (or closely afterwards)? (Can I compare >> it with r167601 or less?) > > I don't believe so - I think only a certain sliding window of logs are > kept (& I don't know of an easy way to view a particular revision > across the bots either)

It looks like dragonegg should have a single buildbot using gcc 4.7. All others would be with 4.6 and 4.5. All the 4.5 and 4.6 ones went red since we reject those compilers now. The 4.7 one is trying to use gcc13, which is currently offline so we now have 0 bot coverage for dragonegg. Can we drop the 4.5 and 4.6 bots and reuse one of the manchines for 4.7? Is there documentation somewhere on how

Hi Andrew, it looks like your commit r139842 | atrick | 2011-09-15 22:58:37 +0200 (Thu, 15 Sep 2011) | 2 lines Reapply r139759. Disable IV rewriting by default. See PR10916. broke this buildbot: http://lab.llvm.org:8011/builders/llvm-x86_64-linux-checks The failure is a bootstrap failure of llvm-gcc when comparing object files from stages 2 and 3 (which don't match). I was able

I need to apologize to many of you, especially Gabor, for my vitriol over buildbot breakages. I get very enraged by breakages that occur over long periods of time. Here's an attempt to explain why I fly off the handle at these. Before we had buildbots, a random patch would break the system. It would sometimes take a whole day to determine which patch broke it. I came up with the

> If we had a larger set of volunteers that could help qualify releases AND buildbots to continuously test the new release criteria, then we are willing to expand this criteria. We haven't had a lot of volunteers step up in this area though. I don't much like the idea of doing a release with so many buildbots down... Ciao, Duncan.

Hi, I'm sure you have all seen this exception dozens of times, but I cannot figure out what it means and what I am doing wrong. As per suggestion of the list, I have put up a Mingw64 build slave and am frantically trying to get it to work. But the Waterfall display kindly informs me that "exception get_builddir" is the result of the attempt of building. I know I am doing

This bot seems kind of flaky. In the last 100 builds, it has failed "gdb-75-check" 22 times with what is either a linker error or a missing header (or both?): gdb compile failed, /usr/bin/ld: error: /home/buildslave/osuosl_slave/clang-x86_64-ubuntu-gdb-75/clang-tests/build/gdb/testsuite/gdb.trace/pendshr1.c.o: requires dynamic R_X86_64_PC32 reloc against 'pendfunc1' which