From: "Theodore Ts'o" <tytso@mit.edu>
To: David Disseldorp <ddiss@suse.de>
Cc: fstests@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] add option to rerun failed tests
Date: Fri, 24 Jun 2022 11:18:58 -0400 [thread overview]
Message-ID: <YrXV4lm4oqKDdl5F@mit.edu> (raw)
In-Reply-To: <20220624103243.10188970@suse.de>
On Fri, Jun 24, 2022 at 10:32:43AM +0200, David Disseldorp wrote:
> Yes, I forgot to mention that, sorry. As Zorro indicated, these were
> done atop the v2022.06.12 tag with the following series applied:
> https://lore.kernel.org/fstests/20220620192934.21694-1-ddiss@suse.de/
Got it, thanks. Sorry, I had forgotten that we had the next branch now.
I'll try to do a full review once I'm able to give the patches a spin.
> > <testcase classname="xfstests.global" name="generic/476" time="354">
> > <failure message="Test failed, reason unknown" type="TestFail" />
> > <system-out>
> > ...
> > </testcase>
> > <testcase classname="xfstests.global" name="generic/476" time="343">
> > </testcase>
> > <testcase classname="xfstests.global" name="generic/476" time="353">
> > </testcase>
> > ...
>
> That seems sensible, I'll add this functionality.
I *think* that should happen automatically when _make_testcase_report
gets called after each iteration. So that might be easier than having
to do any kind of special case handling. (Which is why that was going
to be how I was planning on tackling it before you went ahead and
implemented --- thanks for that!!)
> > As far as haivng the .bad and .full files, I agree that some kind of
> > .rerun-NN suffix would make a lot of sense.
>
> I had a bit of a play with this and it does get a bit ugly if we want to
> prefix things like .dmesg as well. The xunit rerun entries will already
> capture everything, but I suppose it's still needed for those not using
> xunit reports.
Well, actually, one of the things on my TODO list was to implement a
new report type which would removed the xunit <system-out> fields from
the xunit file. The reason behind that is sometimes the the
NNN.out.bad files can get huge --- and the Python library for parsing
junit XML files has a safety mechanism which will error out if a field
is larger than 10MB, to prevent some denial of service attacks. And
I've had some XFS NNN.out.bad files get to be 30MB or larger!
When that happens, it causes the Python script I use to parse the XML
file to fail. In addition, since I already have a different mechanism
for saving the full set of test artifiacts ---- sometimes having the
NNN.full file is really useful for root causing the failure --- having
two copies of the out.bad files in both the Xunit file and in my test
artifacts tarball is a bit of a waste.
I had a POC which implemented this, but then Darrick had a feature
request, since for his workflow, it would be useful if saved only the
first N lines and last N lines in the xunit file, since that's
typically sufficient to figure out what's going on. And I haven't had
a chance to get back to it.
- Ted
next prev parent reply other threads:[~2022-06-24 15:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 16:01 [RFC PATCH 0/2] add option to rerun failed tests David Disseldorp
2022-06-21 16:01 ` [RFC PATCH 1/2] check: append bad / notrun arrays in helper function David Disseldorp
2022-06-21 16:01 ` [RFC PATCH 2/2] check: add -L <n> parameter to rerun failed tests David Disseldorp
2022-06-24 4:42 ` [RFC PATCH 0/2] add option " Theodore Ts'o
2022-06-24 6:15 ` Zorro Lang
2022-06-24 8:32 ` David Disseldorp
2022-06-24 15:18 ` Theodore Ts'o [this message]
2022-06-27 22:02 ` David Disseldorp
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=YrXV4lm4oqKDdl5F@mit.edu \
--to=tytso@mit.edu \
--cc=ddiss@suse.de \
--cc=fstests@vger.kernel.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