similar to: [LLVMdev] llvm-lit JUnit XML output

Yes! That would be really great! > On Aug 13, 2014, at 3:09 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 12 Aug 2014, at 19:34, Chris Matthews <chris.matthews at apple.com> wrote: >> >> The most notable change will be a switch from Buildbot to Jenkins. > > We're currently running LLVM test builds in Jenkins and I have patched

David, I like your patch. I applied the feedback in Phabricator and tested internally. Is it your intent to contribute the patch? I could commit the revised version on your behalf? > On Aug 14, 2014, at 2:41 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > I've put the diff in Phabricator here: > > http://reviews.llvm.org/D4901 > > If you think

I'd be interested in seeing what you have planned upstreamed. I've used Jenkins on several projects. Will Zorg be a vehicle for transition, where buildbot slaves become Jenkins nodes defined in the project files? Do you see a majority of this this as a jenkins matrix project, or some other organization? Rick On 08/13/2014 05:09 AM, David Chisnall wrote: > On 12 Aug 2014, at

There as been a bit of talk about zorg recently, so I thought this would be a good time to share our plans for the darwin buildbots that live here: http://lab.llvm.org:8013/builders <http://lab.llvm.org:8013/builders> To be clear, those are not these buildbots: http://lab.llvm.org:8011/builders <http://lab.llvm.org:8011/builders> We are not talking about changing the main

I have added a Jenkins check for this test, which explains why it fails on some builds. Can we change the test to keep its output? Will it just be blank anyways? > On Jan 20, 2016, at 1:23 PM, Kostya Serebryany <kcc at google.com> wrote: > > The test fails again:

On Wed, Jan 20, 2016 at 1:31 PM, Chris Matthews <chris.matthews at apple.com> wrote: > I worded that poorly, the Jenkins check I added will explain to the user > that we know this fails sometimes. > > On Jan 20, 2016, at 1:30 PM, Chris Matthews <chris.matthews at apple.com> > wrote: > > I have added a Jenkins check for this test, which explains why it fails on

On 14 August 2014 11:13, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > Our Jenkins config just runs llvm-lit manually after building (we use Ninja not make in Jenkins because it's vastly faster for incremental builds and we have several LLVM forks / versions that we test). I agree that having a make / ninja target for the check would be useful, but the lit option was the

On 14 August 2014 11:26, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > So you don't want to send it to the standard output. The things that want to parse it expect a file in the filesystem. So if you want the verbose build to be sticking it in a well-known file then I don't have strong objections, but it seems to be conflating two things. We run lit in -q mode in

On 14 August 2014 10:41, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > I've put the diff in Phabricator here: > > http://reviews.llvm.org/D4901 > > If you think it looks vaguely sensible then let me know and I'll commit it. Hi David, Is there an option for "make check-all"? Or do you have to call lit in a special way inside Jenkins? --renato

These ran to completion without error. :( > On Jan 12, 2016, at 3:23 PM, Chris Matthews <chris.matthews at apple.com> wrote: > > I’m running this on green-dragon-03 which is running OSX 10.10.5. > > /Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace\@2/clang-build/bin/clang++ ../llvm/projects/compiler-rt/test/tsan/mmap_stress.cc -lpthread > while

Ah ha! I found crash reports: green-dragon-03:DiagnosticReports buildslave$ cat mmap_stress.cc.tmp_2016-01-19-231335_green-dragon-03.crash Process: mmap_stress.cc.tmp [95010] Path: /Users/USER/*/mmap_stress.cc.tmp Identifier: mmap_stress.cc.tmp Version: 0 Code Type: X86-64 (Native) Parent Process: bash [95004] User ID:

It is expected and not unusual to need to update the lit test in such case. I'd need to see exactly which test breaks and how to know though. Best, -- Mehdi 2017-09-18 13:17 GMT-07:00 Johan Engelen <jbc.engelen at gmail.com>: > The fix (https://reviews.llvm.org/D37961) does not work. From what I > have learned thusfar, the module identifier is used as filename sometimes >

Yes I can reproduce this locally. It looks like we are not passing an -isysroot (pointing to the SDK) to clang but it isn’t clear what lit magic would expand this. -- adrian > On Nov 13, 2017, at 3:30 PM, Zachary Turner <zturner at google.com> wrote: > > Yea I'm preparing a revert right now. Does it happen for you when you run debuginfo-tests locally? > > On Mon, Nov

Since this is causing all of our internal CI to back up, could you please revert your two changes, so we can make sure that they were actually responsible, and can work on a fix for this? Let me know how we can help investigate this. -- adrian > On Nov 13, 2017, at 3:25 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The first build where a test fails with

Yea I also just found it. Try adding this code in the bottom of debuginfo-tests/lit.cfg.py lit.util.usePlatformSdkOnDarwin(config, lit_config) On Mon, Nov 13, 2017 at 4:38 PM Adrian Prantl <aprantl at apple.com> wrote: > Ha! Found it. *Somebody* is setting an SDKROOT variable in the > environment. Can you find the code that would do this? > > — adrian > > > On Nov

On the other hand this file hasn't changed recently, but I have no way to test this as it uses the LLDB code path, which only runs on OSX. On Mon, Nov 13, 2017 at 3:19 PM Zachary Turner <zturner at google.com> wrote: > I might be missing something, but this doesn't look like me? > > >

Great! It's close to the end of the day, so I'll submit tomorrow to make sure everything has a chance to go fully green again to ensure I get failure emails if it breaks. On Mon, Nov 13, 2017 at 4:43 PM Adrian Prantl <aprantl at apple.com> wrote: > I can confirm that that fixes the issue! > > — adrian > > > On Nov 13, 2017, at 4:38 PM, Zachary Turner <zturner

Hi Zackary, Did you see my followup to you cfe-commits rollback: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171120/210212.html I think you can just remove the change to cfe/trunk/test/CMakeLists.txt and it should work just fine. hth... don On Tue, Nov 21, 2017 at 12:00 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just an update, > > At

It looks like this broke green dragon: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/40383/console llvm-lit: /Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/llvm/projects/libcxx/utils/libcxx/test/config.py:173: note: Adding environment variables: {'DYLD_LIBRARY_PATH': '/Users/buildslave/jenkins/workspace/clang-stage1-configure-RA/clang-build/./lib',

Hi Zachary: I was able to reproduce the greendragon results locally (OSX), and fix the problem by excluding 'debuginfo-tests' from check-clang -- this prevents them from being added twice, once for check-clang and again for check-debuginfo. Below are the minimized patches I used to reproduce and fix the problem -- based on your originals. I've verified these patches work when