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 00:42:03 -0400 [thread overview]
Message-ID: <YrVAm6dzTUh3ufb6@mit.edu> (raw)
In-Reply-To: <20220621160153.29591-1-ddiss@suse.de>
On Tue, Jun 21, 2022 at 06:01:51PM +0200, David Disseldorp wrote:
> This RFC patchset adds support to loop on failed tests, as proposed by
> Ted Ts'o in https://lwn.net/Articles/897061/:
> add a mode that will immediately rerun a failed test 25 or 100 times
> to establish a failure percentage.
>
> There are a couple of things which I'd like to resolve before dropping
> the RFC flag, but would appreciate early feedback on the approach here.
This is really exciting! I was hoping to try it out, but the first
patch doesn't apply to origin/master on xfstests-dev.
For example this patch hunk:
@@ -729,9 +750,7 @@ function run_section()
prev_seq=""
for seq in $list ; do
# Run report for previous test!
- if [ "$tc_status" == "fail" ]; then
- bad+=("$seqnum")
- fi
+ _stash_test_status "$seqnum" "$tc_status"
if $do_report && [[ ! $tc_status =~ ^(init|expunge)$ ]]; then
_make_testcase_report "$prev_seq" "$tc_status"
fi
The relevant section of check looks like this:
# Run report for previous test!
if $err ; then
bad="$bad $seqnum"
n_bad=`expr $n_bad + 1`
tc_status="fail"
fi
And "git blame" shows that this part of check hasn't changed since
2018, and I'm on the latest version upstream version of xfstests:
commit 568ac9fffeb6afec03e5d6c9936617232fd7fc6d (HEAD, tag: v2022.06.05, origin/master, origin/HEAD, kernel/master)
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Jun 3 11:54:13 2022 +1000
xfs/189: systemd monitoring of /etc/fstab sucks
Was your patch based xfstests with some out-of-tree patches?
> The caveats are:
> - rerun tests will be tracked as a single failure in @try and @bad
> + xunit reports do not include any rerun details
> - .bad files generated on failure will be overwritten by test reruns
>
> For xunit reports, I think it'll make sense to stash the aggregates in a
> separate <test>.agg-results file or something. Similarly for .bad file
> overwrites, I could add a .<rerun #> suffix for capturing all failure
> data.
For xunit results fie, was assuming that simply we would just have
multiple repeated testcase entries stored in the single results.xml
file. For example:
<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>
...
I don't know that we need a separate file for the rerun tests, since
it's not that hard to create a python script which parses the results
and calculates the pass/fail percentages for any test which is run
mutiple times.
As far as haivng the .bad and .full files, I agree that some kind of
.rerun-NN suffix would make a lot of sense.
Cheers,
- Ted
next prev parent reply other threads:[~2022-06-24 4:42 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 ` Theodore Ts'o [this message]
2022-06-24 6:15 ` [RFC PATCH 0/2] add option " Zorro Lang
2022-06-24 8:32 ` David Disseldorp
2022-06-24 15:18 ` Theodore Ts'o
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=YrVAm6dzTUh3ufb6@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