[OE-core] [PATCHv2] insane.bbclass: write QA issues to log file only when they are in ERROR_QA or WARN_QA

Martin Jansa martin.jansa at gmail.com
Mon Aug 21 21:27:09 UTC 2017


> You could do "grep -v version-going-backwards qa.log" I guess?

In theory yes, in practice the same jenkins jobs are building different
DISTROs or different Yocto releases with different QA flags enabled, so I
would end up with using bitbke -e to find
WARN_QA and ERROR_QA for given build and then filter only those from qa.log.

I can still do it outside OE, I just didn't realize that there are reasons
for not wanting the levels in the log file (and I still don't know why it's
a good thing not to have them).

Regards,

On Mon, Aug 21, 2017 at 11:23 PM, Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Mon, 2017-08-21 at 23:13 +0200, Martin Jansa wrote:
> > > all messages are put into the log but at differing log levels.
> >
> > But there aren't the "log levels" in the file (as NOTE, WARN, ERROR)
> > now, it writes only P, error message and type of QA check (not the
> > selected severity of it, like bb.error, bb.warn, bb.note used in the
> > function for normal output).
> >
> > See the function above package_qa_handle_error:
> >
> > def package_qa_write_error(type, error, d):
> >     logfile = d.getVar('QA_LOGFILE')
> >     if logfile:
> >         p = d.getVar('P')
> >         with open(logfile, "a+") as f:
> >             f.write("%s: %s [%s]\n" % (p, error, type))
> >
>
> Sorry, I misread your earlier message and assumed it was logging the
> level already. I've spent too long staring at bitbake server bugs :/.
>
> I'm still torn on this, I can see why qa.log makes sense to contain all
> the qa issues found and then the WARN/ERROR levels filter the console
> output (and ultimately the bitbake exit code). I can also see why in
> general we'd not want "levels" in the logfile, its more of a console
> issue.
>
> You could do "grep -v version-going-backwards qa.log" I guess?
>
> Cheers,
>
> Richard
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170821/47227af6/attachment-0002.html>


More information about the Openembedded-core mailing list