similar to: [LLVMdev] llvmlab (phased buildmaster) is in production mode!

Most of the selections, like "console" for example, do not work when I click on them. On 03/27/2013 03:57 PM, Michael Gottesman wrote: > Hello LLVM Dev and Clang Dev! > > David Dean and I just finished bringing up a new build master on > lab.llvm.org <http://lab.llvm.org/>, llvmlab, which is located at the > url http://lab.llvm.org:8013

On Mar 27, 2013, at 6:41 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Mar 27, 2013 at 3:57 PM, Michael Gottesman <mgottesman at apple.com> wrote: > 3. Later phases do broader, longer lasting testing than earlier phases. Thus the 4 phases we currently have are: > > a. Phase 1 (sanity): Phase 1 is a quick non-bootstrapped, non-lto

On Wed, Mar 27, 2013 at 3:57 PM, Michael Gottesman <mgottesman at apple.com>wrote: > 3. Later phases do broader, longer lasting testing than earlier phases. > Thus the 4 phases we currently have are: > > a. Phase 1 (sanity): Phase 1 is a quick non-bootstrapped, non-lto > compiler build, to check the ``basic sanity'' of the code base and build > process.

Cool! This is great news. I feel like this information should be in our documentation somewhere. Could you start a new file ContinuousIntegration.rst and use this content to seed it? This new page would also be a good place to mention some LLVM idiosyncrasies like smooshlab being Apple-internal but still reporting via IRC; these things have not had a good place to be put yet. AFAIK currently our

Hi All, Recent conversations [1][2] would suggest we need to rethink zorg or at the very least improve the documentation. I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands because it seemed that they have contributed the most code to Zorg Organisation ========= The current organisation of the Zorg repository doesn't make a huge amount of sense from my perspective. There

(I said the same thing in my last email = p, except a bit more conservative: do a clean build after 3 failures or something along those lines). Michael On Mar 28, 2013, at 6:16 AM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Mar 27, 2013 at 10:09:59PM -0700, Michael Gottesman wrote: >> Incremental builds are quicker but less robust than clean builds. >

On Wed, Mar 27, 2013 at 10:09:59PM -0700, Michael Gottesman wrote: > Incremental builds are quicker but less robust than clean builds. Can you do add clean-after-error behavior? I.e. default to incremental build, but do a clean rebuild after a failing build? Joerg

Hello everyone, Zorg is a common code for multiple different buildbot setups. This is why it sits in its own subtree. The only tricky thing there is that it assumes some relative position of zorg and master setup. Documenting this would save somebody some time. All together wasn't a problem so far. But having a better documentation and a set of files for a simple local setup is a good idea.

> On Jun 30, 2016, at 1:26 AM, Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > On 30 June 2016 at 05:14, Tim Northover <t.p.northover at gmail.com> wrote: >>> That makes it fragile, and that’s why I disagree with your “90% done” assessment. >>> What if the service behing the hook is down for a few days? >> >> In the long-term

On Thu, Nov 15, 2012 at 2:10 PM, Sean Silva <silvas at purdue.edu> wrote: > kinda random, but do we have a centralized list of all of the > buildbots? I see a lot of different URL's in IRC, but no list so I can > check "all of the waterfalls". I'm not talking about the specific bots > (e.g. llvm-x86_64-ubuntu) but the "fleets"

Hi Galina, > LLVM buildmaster is up and running as lab.llvm.org:8011. ... > Buildslave owners, please contact me directly with your new passwords > and I'll update the master as soon as I can. should build slaves now use the osuosl configuration? For example osuosl/Config.py has def getBuildmasterHost(): return 'google1.osuosl.org' which is surely wrong now. On

On 15.11.2012, at 23:16, David Blaikie <dblaikie at gmail.com> wrote: > On Thu, Nov 15, 2012 at 2:10 PM, Sean Silva <silvas at purdue.edu> wrote: >> kinda random, but do we have a centralized list of all of the >> buildbots? I see a lot of different URL's in IRC, but no list so I can >> check "all of the waterfalls". I'm not talking about the

On 3 January 2013 20:53, Michael Gottesman <mgottesman at apple.com> wrote: > All of our internal testers use LNT. LNT behind the scenes just calls the > Makefiles appropriately. So it would be impossible to get rid of the > makefile execution without gutting LNT as well = p. > Hi Michael, The idea was never to gut the makefiles or LNT, but to let all buildbots use LNT to call

Here is a trivial reason why I have not propagated http://bb.pgr.jp/ . Sometimes (but I suppose rarely) he reports false alarm in a few points. He'd send blames to the llvm-testresults if his master (aka I) knew he were mature. I don't also want him promoted and called as one of official buildbots. He is my pet, though, I expect he should be helpful to the developers. ...Takumi

> On Jul 5, 2016, at 3:44 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Quick re-cap. > > After a few rounds, not only the "external server" proposal got > obliterated as totally unnecessary, but the idea that we may even need > a hook at all is now challenged. This is not clear to me. How is the umbrella repository updated? —

I am happy to announce we are contributing one of our favorite internal tools: llvm bisect! First: I want to thank Daniel Dunbar for writing all the code for this tool, and Google for providing cloud storage and bandwidth to host it! We keep the compilers we build in the Green Dragon CI cluster, and now upload them to the Google Storage Cloud. The llvmlab bisect tool, takes those compilers

On 7 January 2013 14:37, Duncan Sands <baldrick at free.fr> wrote: > sorry, what change do you plan to make? Did you work out what the bug is? > My > basic worry is that it sounds like you are trying to hide the underlying > issue > rather than fixing it, please correct me if I'm wrong. Hi Duncan, There are two issues: 1. The LTO bug we found by running Livermore

On 30 June 2016 at 05:14, Tim Northover <t.p.northover at gmail.com> wrote: >> That makes it fragile, and that’s why I disagree with your “90% done” assessment. >> What if the service behing the hook is down for a few days? > > In the long-term view, a pretty trivial catch-up script ought to be > able to synthesize a sane history after any amount of down-time. >

On 3 January 2013 16:37, David Blaikie <dblaikie at gmail.com> wrote: > My only hesitation here is that using LNT as the authoritative runner > does have a little more setup overhead for people wishing to run the > suite (they need to install some extra stuff). > Yes, there is an issue on shared machines, regarding installing new software (mainly the virtualenv, since lnt

On Feb 15, 2010, at 1:17 PM, David Greene wrote: > On Monday 15 February 2010 15:08:22 Chris Lattner wrote: >> On Feb 15, 2010, at 1:04 PM, David Greene wrote: >>>> FWIW, this is because you broke the encoding of an instruction in your >>>> patch. This is incorrect: >>>> >>>> +def MOVNTDQ_64mr : PSI<0xE7, MRMDestMem, (outs), (ins