<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Jul 20, 2015 at 10:57 AM roger peppe <<a href="mailto:rogpeppe@gmail.com">rogpeppe@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20 July 2015 at 14:11, Martin Packman <<a href="mailto:martin.packman@canonical.com" target="_blank">martin.packman@canonical.com</a>> wrote:<br>
> The logs are giant,<br>
> the actual failure lines tend to be non-informative with the real<br>
> cause several screens up in the log, multiple tests have basically the<br>
> same problems with common code...<br>
<br>
FWIW I often delete all lines containing the string "[LOG]" before<br>
looking at the output - it helps me to see the wood from the trees.<br></blockquote><div><br></div><div>Also FWIW, this is why I wrote <a href="https://github.com/natefinch/nolog">https://github.com/natefinch/nolog</a> - it filters out the spammy logging by default, and offers a few other niceties (many that Horacio added). It's a go application, so just 'go get' it.</div><div><br></div><div>I know that doesn't help when reading CI output, but it is super handy when reproducing a problem locally.  (Yes you could run some combination of linux CLI invocations to do the same thing - this is easier).</div><div><br></div><div><br></div></div></div>