All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: alexis.lothore@bootlin.com, openembedded-core@lists.openembedded.org
Cc: alexandre.belloni@bootlin.com, thomas.petazzoni@bootlin.com
Subject: Re: [OE-core] [PATCH v3 0/6] scripts/resulttool/regression: add metadata filtering
Date: Fri, 24 Feb 2023 18:06:41 +0000	[thread overview]
Message-ID: <05acd5da34f737af11848e110d6f87b44deea3bb.camel@linuxfoundation.org> (raw)
In-Reply-To: <20230224164555.67634-1-alexis.lothore@bootlin.com>

Hi Alexis,

Firstly, this looks very much improved, thanks. It is great to start to
see some meaningful data from this.

On Fri, 2023-02-24 at 17:45 +0100, Alexis Lothoré via
lists.openembedded.org wrote:
> From: Alexis Lothoré <alexis.lothore@bootlin.com>
> 
> Hello,
> this new series is the follow-up of [1] to make regression reports more
> meaningful, by reducing noise and false positives.
> 
> Change since v2:
> - add filtering on MACHINE field from test results configuration: the MACHINE
>   should always match
> - add "metadata guessing" mechanism based on Richard proposal ([2]). Up to the
>   point where this series will be merged, tests results stored in git are not
>   enriched with OESELFTEST_METADATA. To allow proper test comparison even with
>   those tests, try to guess what oeselftest command line has been used to run
>   the corresponding tests, and generate OESELFTEST_METADATA accordingly
> - add new tool to ease test results usage: yocto_testresults_query. For now the
>   tool only manages regression report and is a thin layer between send-qa-email
>   (in yocto-autobuilder-helper) and resulttool. Its main role is to translate
>   regression reports arguments (which are tags or branches) to fixed revisions
>   and to call resulttool accordingly. Most of its code is a transfer from
>   send-qa-email (another series for the autobuilder will follow this one to make
>   send-qa-email use this new helper, but this current series works
>   independently)
>   Example: "yocto_testresults_query.py regression-report 4.2_M1 4.2_M2" will
>   replay the regression report generated when the 4.2_M2 has been generated.
> 
> Change since v1:
> - properly configure "From" field in series
> 
> With those improvements, the regression report is significantly reduced and some
> useful data start to emerge from the removed noise:
> - with the MACHINE filtering, the 4.2_M2 report goes from 5.5GB to 627MB
> - with the OESELFTEST_METADATA enrichment + metadata guessing for older tests,
>   the report goes from 627MB to 1.5MB

That is just a bit more readable!

> 
> After manual inspection on some entries, the remaining oeselftest regression
> raised in the report seems valid. There are still some issues to tackle:
> - it seems that now one major remaining source of noise is on the "runtime"
>   tests (comparison to tests not run on "target" results)
> - when a ptest managed by oe-selftest fails, I guess the remaining tests are not
>   run, so when 1 failure is logged, we have many "PASSED->None" transitions in
>   regression report, we should probably silence it.
> - some transitions appear as regression while those are in fact improvements
>   (e.g: "UNRESOLVED->PASSED")

I had quick play. Firstly, if I try "yocto_testresults_query.py
regression-report 4.2_M1 4.2_M2" in an openembedded-core repository
instead of poky, it breaks. That isn't surprising but we should either
make it work or show a sensible error.

I also took a look the report and wondered why the matching isn't quite
right and why we have these "regressions". If we could remove that
noise, I think we'd get down to the real issues. I ended up doing:

resulttool report --commit 4d19594b8bdacde6d809d3f2a25cff7c5a42295e  . > /tmp/repa
resulttool report --commit 5e249ec855517765f4b99e8039cb888ffa09c211  . > /tmp/repb
meld /tmp/rep*

which was interesting as gave lots of warnings like:

"Warning duplicate ptest result 'acl.test/cp.test' for qemuarm64"

so it looks like we had a couple of different test runs for qemuarm64
ptests which is confusing your new code. I suspect this happened due to
some autobuilder glitch during the release build which restarted some
of the build pieces. Not sure how to handle that yet, I'll give it some
further thought but I wanted to share what I think is the source of
some of the issues. Basically we need to get the regression report
looking more like that meld output!

Cheers,

Richard


  parent reply	other threads:[~2023-02-24 18:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 16:45 [PATCH v3 0/6] scripts/resulttool/regression: add metadata filtering alexis.lothore
2023-02-24 16:45 ` [PATCH v3 1/6] scripts/oe-selftest: append metadata to tests results alexis.lothore
2023-02-24 16:45 ` [PATCH v3 2/6] scripts/resulttool/regression: remove unused import alexis.lothore
2023-02-24 16:45 ` [PATCH v3 3/6] scripts/resulttool/regression: add metadata filtering for oeselftest alexis.lothore
2023-02-24 16:45 ` [PATCH v3 4/6] oeqa/selftest/resulttool: add test for metadata filtering on regression alexis.lothore
2023-02-26  0:03   ` [OE-core] " Richard Purdie
2023-02-24 16:45 ` [PATCH v3 5/6] scripts: add new helper for regression report generation alexis.lothore
2023-02-24 16:45 ` [PATCH v3 6/6] oeqa/selftest: add test for yocto_testresults_query.py alexis.lothore
2023-02-24 18:06 ` Richard Purdie [this message]
     [not found] ` <1746D4E8592324E9.29542@lists.openembedded.org>
2023-02-25  9:15   ` [OE-core] [PATCH v3 0/6] scripts/resulttool/regression: add metadata filtering Richard Purdie
     [not found]   ` <1747067DAE80068A.29542@lists.openembedded.org>
2023-02-25 12:32     ` Richard Purdie
2023-02-25 15:59       ` Alexis Lothoré
2023-02-26 12:15         ` Richard Purdie
2023-02-26 15:42           ` Alexis Lothoré
2023-02-27 13:41             ` Richard Purdie
     [not found]     ` <1747113C8A4DBAD6.29542@lists.openembedded.org>
2023-02-25 12:44       ` Richard Purdie
2023-02-27 13:14         ` Ross Burton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=05acd5da34f737af11848e110d6f87b44deea3bb.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.