From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: zlang@redhat.com, linux-xfs@vger.kernel.org,
fstests@vger.kernel.org, guan@eryu.me, leah.rumancik@gmail.com,
quwenruo.btrfs@gmx.com
Subject: Re: [PATCH 6/8] report: collect basic information about a test run
Date: Tue, 14 Feb 2023 10:59:38 -0800 [thread overview]
Message-ID: <Y+vaGoCosvF5JH3n@magnolia> (raw)
In-Reply-To: <Y6EsNkIcA7bd9aHR@mit.edu>
On Mon, Dec 19, 2022 at 10:29:58PM -0500, Theodore Ts'o wrote:
> On Mon, Dec 19, 2022 at 04:01:37PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > Record various generic information about an fstests run when generating
> > a junit xml report. This includes the cpu architecture, the kernel
> > revision, the CPU, memory, and numa node counts, and some information
> > about the block devices passed in.
>
> It would be nice if there was a way that the test runner could pass
> information that would be added to the xunit properties. As I
> mentioned in another e-mail, I currently do this via a post-processing
> step which adds the properties to the junit xml file via a python
> script. And there are a number of additional properties that are used
> by my report generator[1] which takes the junit xml file as input, and
> generates a summary report which is convenient for humans.
>
> [1] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/usr/local/bin/gen_results_summary
>
> Some of these properties include the version of xfstests, xfsprogs,
> and other key software components (for example, I've had test failures
> traced to bugs in fio, so knowing the version of fio that is used is
> super-handy).
>
> So maybe we could pass in a properties file, either via a command-line
> option or an environment variable? My script[2] uses a colon
> separated format, but I'm not wedded to that delimiter.
>
> CMDLINE: "-c f2fs/default -g auto"
> FSTESTIMG: gce-xfstests/xfstests-amd64-202212131454
> FSTESTPRJ: gce-xfstests
> KERNEL: kernel 6.1.0-xfstests #2 SMP PREEMPT_DYNAMIC Mon Dec 12 16:09:40 EST 2022 x86_64
> FSTESTVER: blktests 068bd2a (Fri, 18 Nov 2022 08:38:35 +0900)
> FSTESTVER: fio fio-3.31 (Tue, 9 Aug 2022 14:41:25 -0600)
> FSTESTVER: fsverity v1.5 (Sun, 6 Feb 2022 10:59:13 -0800)
> FSTESTVER: ima-evm-utils v1.3.2 (Wed, 28 Oct 2020 13:18:08 -0400)
> FSTESTVER: nvme-cli v1.16 (Thu, 11 Nov 2021 13:09:06 -0800)
> FSTESTVER: quota v4.05-52-gf7e24ee (Tue, 1 Nov 2022 11:45:06 +0100)
> FSTESTVER: util-linux v2.38.1 (Thu, 4 Aug 2022 11:06:21 +0200)
> FSTESTVER: xfsprogs v6.0.0 (Mon, 14 Nov 2022 12:06:23 +0100)
> FSTESTVER: xfstests-bld 65edab38 (Wed, 30 Nov 2022 12:11:57 -0500)
> FSTESTVER: xfstests v2022.11.27-8-g3c178050c (Wed, 30 Nov 2022 10:25:39 -0500)
Do you want the version numbers of each dependency to have a unique
name attribute here?
<property name="FSTESTVER: xfstests" value="v2022.11.27-8-g3c178050c..."/>
Though ... technically speaking, the @name attributes aren't required to
be unique, so this is valid:
<property name="FSTESTVER" value="xfstests-bld 65edab38..."/>
<property name="FSTESTVER" value="xfstests v2022.11.27-8-g3c178050c..."/>
Or I could go with what I've been rambling about on the ext4 concall for
some time now: set EXTRA_REPORT_VARS to a path to a file containing
"name: value" strings, one per line, split on the colon. You all can
translate this into such a format however you like. :)
--D
> FSTESTVER: zz_build-distro bullseye
> FSTESTCFG: "f2fs/default"
> FSTESTSET: "-g auto"
> FSTESTEXC: ""
> FSTESTOPT: "aex"
> MNTOPTS: ""
> CPUS: "2"
> MEM: "7680"
> DMI_MEM: 8 GB (Max capacity)
> PARAM_MEM: 7680 (restricted by cmdline)
> GCE ID: "3198461547210171740"
> MACHINE TYPE: "e2-standard-2"
> TESTRUNID: tytso-20221213150813
>
> [2] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/usr/local/bin/update_properties_xunit
>
> Cheers,
>
> - Ted
next prev parent reply other threads:[~2023-02-14 18:59 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
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 [this message]
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+vaGoCosvF5JH3n@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=tytso@mit.edu \
--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