public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: zlang@redhat.com, linux-xfs@vger.kernel.org,
	fstests@vger.kernel.org, guan@eryu.me, leah.rumancik@gmail.com
Subject: Re: [PATCH 1/8] check: generate section reports between tests
Date: Tue, 14 Feb 2023 10:46:42 -0800	[thread overview]
Message-ID: <Y+vXEjKI08PXe95J@magnolia> (raw)
In-Reply-To: <f447b1ab-ce5d-a736-6427-d1a3f33d20cf@gmx.com>

On Tue, Dec 20, 2022 at 09:14:07AM +0800, Qu Wenruo wrote:
> 
> 
> On 2022/12/20 08:01, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Generate the section report between tests so that the summary report
> > always reflects the outcome of the most recent test.  Two usecases are
> > envisioned here -- if a cluster-based test runner anticipates that the
> > testrun could crash the VM, they can set REPORT_DIR to (say) an NFS
> > mount to preserve the intermediate results.  If the VM does indeed
> > crash, the scheduler can examine the state of the crashed VM and move
> > the tests to another VM.  The second usecase is a reporting agent that
> > runs in the VM to upload live results to a test dashboard.
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >   check |   10 ++++++++++
> >   1 file changed, 10 insertions(+)
> > 
> > 
> > diff --git a/check b/check
> > index 1ff0f44af1..70a0b537b1 100755
> > --- a/check
> > +++ b/check
> > @@ -842,6 +842,16 @@ function run_section()
> >   		fi
> >   		seqres="$REPORT_DIR/$seqnum"
> > +		# Generate the entire section report with whatever test results
> > +		# we have so far.  Leave the $sect_time parameter empty so that
> > +		# it's a little more obvious that this test run is incomplete.
> > +		if $do_report; then
> > +			local sect_now=`_wallclock`
> > +			_make_section_report "$section" "${#try[*]}" \
> > +					     "${#bad[*]}" "${#notrun[*]}" \
> > +					     "" &> /dev/null
> > +		fi
> > +
> 
> In fact that's exactly what I just wanted to do next...
> 
> However one problem I can't work around is the timestamp.
> 
> Currently our timestamp is the finish time, with this change our timestamp
> is the start time.

Er... what do you mean exactly by start and finish time?  The most
recent test?  The entire run?

From check:

	if [ -w /dev/kmsg ]; then
		export date_time=`date +"%F %T"`
		echo "run fstests $seqnum at $date_time" > /dev/kmsg
		...
	fi

From common/report:

	if [ -z "$date_time" ]; then
		date_time=$(date +"%F %T")
	fi

	...timestamp="${date_time/ /T}">

The "date_time" variable can be set by ./check just prior to starting
each test, but only if /dev/kmsg is a writable file.  If it's set, then
the timestamp in the xml file reflects the start time of the most recent
test.

If date_time is not set, then the timestamp in the xml file records the
point in time when the report is generated... which I suppose is a good
enough estimate if we failed to record date_time when the test was
started.

> I'm not sure if there is any strong definition on the timestamp, but
> personally speaking, timestamp for the start time makes more sense to me.
> But there may be some users relying on the timestamp to be the ending time?

The junit xml schema says that the timestamp should be "when the test
was executed".  I think ./check ought to be setting date_time regardless
of /dev/kmsg.  ATM my test dashboard computes the difference between now
and the timestamp= attribute of the last report received to decide if it
should flag a test VM as possibly stalled.

Though to undercut everything I just wrote, the junit xml schema defines
testsuite and testcase as distinct entities and then refers to "the
test".

Given that fstests doesn't strictly follow that schema anyway, I guess
we can define the timestamp as we want, or add more timestamp
attributes?

<testsuite suite_timestamp="..." timestamp="..." report_timestamp="..."...>

--D

> Thanks,
> Qu
> 
> >   		mkdir -p $RESULT_DIR
> >   		rm -f ${RESULT_DIR}/require_scratch*
> >   		rm -f ${RESULT_DIR}/require_test*
> > 

  reply	other threads:[~2023-02-14 18:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20  0:01 [PATCHSET RFC 0/8] fstests: improve junit xml reporting Darrick J. Wong
2022-12-20  0:01 ` [PATCH 1/8] check: generate section reports between tests Darrick J. Wong
2022-12-20  1:14   ` Qu Wenruo
2023-02-14 18:46     ` Darrick J. Wong [this message]
2023-02-15  2:06       ` Qu Wenruo
2022-12-20  3:16   ` Theodore Ts'o
2022-12-20 18:18     ` Leah Rumancik
2022-12-20  0:01 ` [PATCH 2/8] report: derive an xml schema for the xunit report Darrick J. Wong
2022-12-20  2:18   ` Qu Wenruo
2023-02-14 18:54     ` Darrick J. Wong
2022-12-20  0:01 ` [PATCH 3/8] report: capture the time zone in the test report timestamp Darrick J. Wong
2022-12-20  2:19   ` Qu Wenruo
2022-12-20  0:01 ` [PATCH 4/8] report: sort properties by name Darrick J. Wong
2022-12-20  0:01 ` [PATCH 5/8] report: pass property value to _xunit_add_property Darrick J. Wong
2022-12-20  0:01 ` [PATCH 6/8] report: collect basic information about a test run Darrick J. Wong
2022-12-20  3:29   ` Theodore Ts'o
2023-02-14 18:59     ` Darrick J. Wong
2022-12-20  0:01 ` [PATCH 7/8] report: record xfs-specific " Darrick J. Wong
2022-12-20  0:01 ` [PATCH 8/8] report: record ext*-specific " Darrick J. Wong

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=Y+vXEjKI08PXe95J@magnolia \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=leah.rumancik@gmail.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=zlang@redhat.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