From: richard.purdie@linuxfoundation.org
To: "Yeoh, Ee Peng" <ee.peng.yeoh@intel.com>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/4] oeqa/core/runner: write testresult to json files
Date: Mon, 15 Oct 2018 09:59:59 +0100 [thread overview]
Message-ID: <b3886f4b8368d523f999a2706e18cd36b257d084.camel@linuxfoundation.org> (raw)
In-Reply-To: <9DDD2658D1FE414E99172D2DB1E4D04335ECB1EB@KMSMSX155.gar.corp.intel.com>
Hi Ee Peng,
On Mon, 2018-10-15 at 08:42 +0000, Yeoh, Ee Peng wrote:
> Thank you very much for your inputs!
> I had completed making most of the enhancements following your
> inputs, except the 1 input to put test result logs alongside the test
> result data in the json file.
> The concerns I have over putting test result logs into test result
> json file:
> 1. Test result logs will be arbitrary long depending on the type of
> failure/error and tetecase. With test result logs adding to the test
> result json file, it will potentially making it hard to read the json
> file, where the test logs will potentially span over multiple lines.
> 2. By having test logs per each test case in separate file, it will
> allow quick and easy regression of test logs per specific test
> case. By putting all the test logs into the one testresult json
> file, I am worry that it will make regression on test logs per
> specific test case harder.
>
> I hope the concerns above justify keeping test logs separate from
> testresult json file. Please let me know your thoughts and inputs.
The log data and the test results are connected and belong together.
The intent here is to make files which capture the results information
and direct user readability is a secondary issue, these files are not
intended to be directly read by humans.
If we need a clean readable output, I'm imagining we'd have a simple
processing tool which could for example just filter out the test
results.
Having a single results file also makes it easier for the automated
systems to collect up the results files from different autobuilders and
also makes it easier to potentially merge results together.
One piece I suspect may also be missing is that we may need to record
some extra information into these files too, such as the MACHINE,
DISTRO, hostname of the builder that ran them and the revision of the
codebase (layers) used to run the test. There is probably other
information we need to record in order to make these results useful in
the wider context of the project but I do believe it can and should be
recorded in a single file.
Does that help explain why I'm asking for this?
Cheers,
Richard
next prev parent reply other threads:[~2018-10-15 9:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-12 6:33 [PATCH 1/4] oeqa/core/runner: write testresult to json files Yeoh Ee Peng
2018-10-12 6:33 ` [PATCH 2/4] oeqa/selftest/context: " Yeoh Ee Peng
2018-10-12 6:33 ` [PATCH 3/4] testimage.bbclass: " Yeoh Ee Peng
2018-10-12 15:10 ` Richard Purdie
2018-10-12 6:33 ` [PATCH 4/4] testsdk.bbclass: " Yeoh Ee Peng
2018-10-12 15:00 ` [PATCH 1/4] oeqa/core/runner: " Richard Purdie
2018-10-15 8:42 ` Yeoh, Ee Peng
2018-10-15 8:59 ` richard.purdie [this message]
2018-10-15 10:00 ` Yeoh, Ee Peng
-- strict thread matches above, loose matches on Subject: below --
2018-10-22 6:54 Yeoh Ee Peng
2018-10-22 8:31 ` Richard Purdie
2018-10-22 8:59 ` Yeoh, Ee Peng
2018-10-22 9:34 ` richard.purdie
2018-10-22 9:47 ` Yeoh, Ee Peng
2018-10-22 10:53 ` Yeoh, Ee Peng
2018-10-22 10:34 Yeoh Ee Peng
2018-10-22 22:54 ` Richard Purdie
2018-10-23 6:39 ` Yeoh, Ee Peng
2018-10-29 10:44 ` richard.purdie
2018-10-29 13:58 ` Richard Purdie
2018-10-30 8:55 ` Yeoh, Ee Peng
2018-10-23 5:57 Yeoh Ee Peng
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=b3886f4b8368d523f999a2706e18cd36b257d084.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=ee.peng.yeoh@intel.com \
--cc=openembedded-core@lists.openembedded.org \
/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