Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Robert Yang <liezhi.yang@windriver.com>,
	openembedded-core@lists.openembedded.org,
	paul.eggleton@linux.intel.com, ross.burton@intel.com
Subject: Re: [RFC PATCH 0/5] revive runtime/cases/_ptest.py
Date: Fri, 21 Jul 2017 13:32:45 +0100	[thread overview]
Message-ID: <1500640365.22282.104.camel@linuxfoundation.org> (raw)
In-Reply-To: <0f028eac-d2d0-3ab8-232c-658db5b7cc6d@windriver.com>

On Thu, 2017-07-20 at 10:09 +0800, Robert Yang wrote:
> 
> On 07/19/2017 04:16 PM, Robert Yang wrote:
> > 
> > Hello,
> > 
> > These patches can make ptest test case work, RP has suggested we
> > write a tool to
> > do the regression check on ptest result, I think that the use case
> > is like:
> > 
> > $ bitbake <image> -ctestiamge # Suppose we add ptest to default
> > test cases in the future
> > # Upgrade a recipe form V1.0 to V1.1
> > $ bitbake <image> -ctestiamge # Run the test again
> > 
> > Then the regression check tool can report what's different (passed,
> > failed,
> > skipped) between V1.0 and V1.1.
> > 
> > Currently, I'm not sure about where to save the ptest results, I
> > saved it to
> > ${WORKDIR}/testimage/ptest_log atm, e.g.:
> > tmp/work/qemux86-poky-linux/core-image-minimal/1.0-
> > r0/testimage/ptest_log
> I still have to think about more about where to put the test result.

Would buildhistory make sense for these since we already have a
mechanism to store results there between builds?

> > But it will be removed after -cclean, then no regression check can
> > be made, so
> > I'd like to save the ptest results to DEPLOY_DIR_IMAGE if no
> > objections, and
> > make -cclean not remove them. (Or only keep the latest 2 results).
> > 
> > And I'm not sure where to add the regression check/tool, maybe one
> > of:
> > 1) Add a separate tool in oe-core/scripts, this can make it easy to
> > do regression
> >    check among different build directories, and
> > runtime/cases/_ptest.py can invoke it.
> I'm leaning to add a script called ptest-regression-check which is
> more flexible, the cases/ptest.py or buildhistory (also the user) can
> run it when needed.

I'd either add a script, or perhaps an option to the buildhistory-diff? 
Paul might have some adivce on that. I would like to understand if
there is a good reason we can't use buildhistory to at least help with
some of this?

Cheers,

Richard


  reply	other threads:[~2017-07-21 12:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-19  8:16 [RFC PATCH 0/5] revive runtime/cases/_ptest.py Robert Yang
2017-07-19  8:16 ` [RFC PATCH 1/5] oeqa/targetcontrol.py: simplify checking for qemu_use_kvm Robert Yang
2017-07-19  8:16 ` [RFC PATCH 2/5] runtime/cases/_ptest.py: revive it Robert Yang
2017-07-19  8:16 ` [RFC PATCH 3/5] oeqa/utils/logparser.py: add skip status Robert Yang
2017-07-19  8:16 ` [RFC PATCH 4/5] runtime/cases/_ptest.py: " Robert Yang
2017-07-19  8:16 ` [RFC PATCH 5/5] runtime/cases/_ptest.py: rename it to ptest.py Robert Yang
2017-07-20  2:09 ` [RFC PATCH 0/5] revive runtime/cases/_ptest.py Robert Yang
2017-07-21 12:32   ` Richard Purdie [this message]
2017-07-24  2:11     ` Robert Yang

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=1500640365.22282.104.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=liezhi.yang@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=ross.burton@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox