llvm dev - Aug 2014 - [LLVMdev] Plans for the Apple supported Darwin buildbot cluster

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
Jenkins, because we don't want big console logs duplicating the information
in the XML.
I could be wrong, but I thought that buildbots already stored the
standard output into a file for parsing, so Jenkins would possibly do
the same? It seems not.

Since you're requesting an XML output (same as when requesting verbose
textual output), you will get a lot of output, so redirecting stdout
to a file on the integration level seems like the most sensible
solution on the tool level.

cheers,
--renato

I had the impression that xunit output should be an extra file generated. Just
like lit’s current dump command.  So the tests run as they did before, but an
extra report file is produced.

> On Aug 14, 2014, at 4:25 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> 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 Jenkins, because we don't want big console logs duplicating the
information in the XML.
> 
> I could be wrong, but I thought that buildbots already stored the
> standard output into a file for parsing, so Jenkins would possibly do
> the same? It seems not.
> 
> Since you're requesting an XML output (same as when requesting verbose
> textual output), you will get a lot of output, so redirecting stdout
> to a file on the integration level seems like the most sensible
> solution on the tool level.
> 
> cheers,
> --renato

On 8/14/14, 5:25 AM, Renato Golin wrote:
> 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 Jenkins, because we don't want big console logs duplicating the
information in the XML.
>
> I could be wrong, but I thought that buildbots already stored the
> standard output into a file for parsing, so Jenkins would possibly do
> the same? It seems not.
I've observed that Jenkins chokes horribly on test-suites that print a lot
to
standard output (without redirecting to a file). When it's egregiously bad,
you
can even crash Jenkins doing it.

It's best for them not to print so much in order to avoid this issue, and
make
the logs easier to be human read.


Cheers,
Jon
>
> Since you're requesting an XML output (same as when requesting verbose
> textual output), you will get a lot of output, so redirecting stdout
> to a file on the integration level seems like the most sensible
> solution on the tool level.
>
> cheers,
> --renato
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

We have found that you have to bump up the memory that java can use on the
slaves for large jobs, but no problems otherwise (so far).
> On Aug 15, 2014, at 8:59 AM, Jonathan Roelofs <jonathan at
codesourcery.com> wrote:
> 
> 
> 
> On 8/14/14, 5:25 AM, Renato Golin wrote:
>> 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 Jenkins, because we don't want big console logs duplicating the
information in the XML.
>> 
>> I could be wrong, but I thought that buildbots already stored the
>> standard output into a file for parsing, so Jenkins would possibly do
>> the same? It seems not.
> I've observed that Jenkins chokes horribly on test-suites that print a
lot to standard output (without redirecting to a file). When it's
egregiously bad, you can even crash Jenkins doing it.
> 
> It's best for them not to print so much in order to avoid this issue,
and make the logs easier to be human read.
> 
> 
> Cheers,
> Jon
>> 
>> Since you're requesting an XML output (same as when requesting
verbose
>> textual output), you will get a lot of output, so redirecting stdout
>> to a file on the integration level seems like the most sensible
>> solution on the tool level.
>> 
>> cheers,
>> --renato
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
> 
> -- 
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev