* [PATCH] fstests: report: add arch and kernel version info into testsuite attributes @ 2022-12-16 7:05 Qu Wenruo 2022-12-19 17:57 ` Darrick J. Wong 0 siblings, 1 reply; 5+ messages in thread From: Qu Wenruo @ 2022-12-16 7:05 UTC (permalink / raw) To: linux-btrfs, fstests Although "testcase" tags contain the "timestamp" element, for day-0 testing it can be hard to relate the timestamp to the tested kernel version. Thus this patch will add a "kernel" element to the "testcase" tag, to indicate the kernel version we're running. Paired with CONFIG_LOCALVERSION_AUTO=y config, it will easily show the kernel commit we're testing. Since we're here, also add a "arch" element, as there are more and more aarch64 boards (From RK3399 to Apple M1) able to finish fstests in an acceptable duration, we can no longer assume x86_64 as our only platform. Signed-off-by: Qu Wenruo <wqu@suse.com> --- common/report | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/report b/common/report index 4a747f8d..92586527 100644 --- a/common/report +++ b/common/report @@ -49,7 +49,7 @@ _xunit_make_section_report() date_time=$(date +"%F %T") fi local stats="failures=\"$bad_count\" skipped=\"$notrun_count\" tests=\"$tests_count\" time=\"$sect_time\"" - local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" " + local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" arch=\"$(uname -m)\" kernel=\"$(uname -r)\"" echo "<testsuite name=\"xfstests\" $stats $hw_info >" >> $REPORT_DIR/result.xml # Properties -- 2.38.0 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] fstests: report: add arch and kernel version info into testsuite attributes 2022-12-16 7:05 [PATCH] fstests: report: add arch and kernel version info into testsuite attributes Qu Wenruo @ 2022-12-19 17:57 ` Darrick J. Wong 2022-12-19 22:30 ` Qu Wenruo 0 siblings, 1 reply; 5+ messages in thread From: Darrick J. Wong @ 2022-12-19 17:57 UTC (permalink / raw) To: Qu Wenruo; +Cc: linux-btrfs, fstests On Fri, Dec 16, 2022 at 03:05:43PM +0800, Qu Wenruo wrote: > Although "testcase" tags contain the "timestamp" element, for day-0 > testing it can be hard to relate the timestamp to the tested kernel > version. > > Thus this patch will add a "kernel" element to the "testcase" tag, to > indicate the kernel version we're running. > Paired with CONFIG_LOCALVERSION_AUTO=y config, it will easily show the > kernel commit we're testing. > > Since we're here, also add a "arch" element, as there are more and more > aarch64 boards (From RK3399 to Apple M1) able to finish fstests in an > acceptable duration, we can no longer assume x86_64 as our only > platform. > > Signed-off-by: Qu Wenruo <wqu@suse.com> > --- > common/report | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/common/report b/common/report > index 4a747f8d..92586527 100644 > --- a/common/report > +++ b/common/report > @@ -49,7 +49,7 @@ _xunit_make_section_report() > date_time=$(date +"%F %T") > fi > local stats="failures=\"$bad_count\" skipped=\"$notrun_count\" tests=\"$tests_count\" time=\"$sect_time\"" > - local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" " > + local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" arch=\"$(uname -m)\" kernel=\"$(uname -r)\"" > echo "<testsuite name=\"xfstests\" $stats $hw_info >" >> $REPORT_DIR/result.xml The original commit that added this report format was f9fde7db2f ("report: Add xunit format report generator"). Dmitry Monakhov's commit message points out that the xml being emitted was "xunit/junit": Footnotes: [1] https://xunit.github.io/docs/format-xml-v2.html [2] http://help.catchsoftware.com/display/ET/JUnit+Format The first link is now dead, but the second link contains enough information to find the current junit xml format: [1] https://raw.githubusercontent.com/windyroad/JUnit-Schema/master/JUnit.xsd Note that the xunit project appears to have diverged their report format: [2] https://xunit.net/docs/format-xml-v2 (Or perhaps there were multiple things called xunit?) Either way, it's pretty obvious from common/report code that the "xunit" code is still emitting junit xml files. I think it's important that fstests should continue to follow that schema, so that these files can be fed into test dashboards (yes I have one) that consume this file format. Regrettably, the schema does not provide for @arch or @kernel attributes hanging off the <testsuite> element, so it's not a good idea to add things that a strict parser could reject. That said, I think it's important to record the architecture and kernel. Probably even more attributes than that. The junit xml schema provides for arbitrary string properties to be attached to reports; would you mind putting these there instead? (I want to add a few more properties now that people have started talking about reporting again... ;)) # Properties echo -e "\t<properties>" >> $REPORT_DIR/result.xml echo -e "\t\t<property name=\"arch\" value=\"$(uname -m)\"/>" >> $REPORT_DIR/result.xml echo -e "\t\t<property name=\"kernel\" value=\"$(uname -r)\"/>" >> $REPORT_DIR/result.xml for p in "${REPORT_ENV_LIST[@]}"; do _xunit_add_property "$p" done echo -e "\t</properties>" >> $REPORT_DIR/result.xml --D > > # Properties > -- > 2.38.0 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fstests: report: add arch and kernel version info into testsuite attributes 2022-12-19 17:57 ` Darrick J. Wong @ 2022-12-19 22:30 ` Qu Wenruo 2022-12-19 23:48 ` Darrick J. Wong 0 siblings, 1 reply; 5+ messages in thread From: Qu Wenruo @ 2022-12-19 22:30 UTC (permalink / raw) To: Darrick J. Wong, Qu Wenruo; +Cc: linux-btrfs, fstests On 2022/12/20 01:57, Darrick J. Wong wrote: > On Fri, Dec 16, 2022 at 03:05:43PM +0800, Qu Wenruo wrote: >> Although "testcase" tags contain the "timestamp" element, for day-0 >> testing it can be hard to relate the timestamp to the tested kernel >> version. >> >> Thus this patch will add a "kernel" element to the "testcase" tag, to >> indicate the kernel version we're running. >> Paired with CONFIG_LOCALVERSION_AUTO=y config, it will easily show the >> kernel commit we're testing. >> >> Since we're here, also add a "arch" element, as there are more and more >> aarch64 boards (From RK3399 to Apple M1) able to finish fstests in an >> acceptable duration, we can no longer assume x86_64 as our only >> platform. >> >> Signed-off-by: Qu Wenruo <wqu@suse.com> >> --- >> common/report | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/common/report b/common/report >> index 4a747f8d..92586527 100644 >> --- a/common/report >> +++ b/common/report >> @@ -49,7 +49,7 @@ _xunit_make_section_report() >> date_time=$(date +"%F %T") >> fi >> local stats="failures=\"$bad_count\" skipped=\"$notrun_count\" tests=\"$tests_count\" time=\"$sect_time\"" >> - local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" " >> + local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" arch=\"$(uname -m)\" kernel=\"$(uname -r)\"" >> echo "<testsuite name=\"xfstests\" $stats $hw_info >" >> $REPORT_DIR/result.xml > > The original commit that added this report format was f9fde7db2f > ("report: Add xunit format report generator"). Dmitry Monakhov's commit > message points out that the xml being emitted was "xunit/junit": > > Footnotes: > [1] https://xunit.github.io/docs/format-xml-v2.html > [2] http://help.catchsoftware.com/display/ET/JUnit+Format > > The first link is now dead, but the second link contains enough > information to find the current junit xml format: > > [1] https://raw.githubusercontent.com/windyroad/JUnit-Schema/master/JUnit.xsd > > Note that the xunit project appears to have diverged their report > format: > > [2] https://xunit.net/docs/format-xml-v2 Great we have something solid to follow. > > (Or perhaps there were multiple things called xunit?) > > Either way, it's pretty obvious from common/report code that the "xunit" > code is still emitting junit xml files. I think it's important that > fstests should continue to follow that schema, so that these files can > be fed into test dashboards (yes I have one) that consume this file > format. Totally agreed. > > Regrettably, the schema does not provide for @arch or @kernel attributes > hanging off the <testsuite> element, so it's not a good idea to add > things that a strict parser could reject. I'm totally fine with the properties method, but still curious why some parsers would even reject elements with unknown attributes? Isn't the idea of XML (or JSON) to be flex for newer attributes? > > That said, I think it's important to record the architecture and kernel. > Probably even more attributes than that. The junit xml schema provides > for arbitrary string properties to be attached to reports; would you > mind putting these there instead? > > (I want to add a few more properties now that people have started > talking about reporting again... ;)) > > # Properties > echo -e "\t<properties>" >> $REPORT_DIR/result.xml > echo -e "\t\t<property name=\"arch\" value=\"$(uname -m)\"/>" >> $REPORT_DIR/result.xml > echo -e "\t\t<property name=\"kernel\" value=\"$(uname -r)\"/>" >> $REPORT_DIR/result.xml > for p in "${REPORT_ENV_LIST[@]}"; do > _xunit_add_property "$p" > done > echo -e "\t</properties>" >> $REPORT_DIR/result.xml Sounds pretty good, thanks for all the awesome advices! Qu > > --D > >> >> # Properties >> -- >> 2.38.0 >> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fstests: report: add arch and kernel version info into testsuite attributes 2022-12-19 22:30 ` Qu Wenruo @ 2022-12-19 23:48 ` Darrick J. Wong 2022-12-20 0:00 ` Theodore Ts'o 0 siblings, 1 reply; 5+ messages in thread From: Darrick J. Wong @ 2022-12-19 23:48 UTC (permalink / raw) To: Qu Wenruo; +Cc: Qu Wenruo, linux-btrfs, fstests On Tue, Dec 20, 2022 at 06:30:10AM +0800, Qu Wenruo wrote: > > > On 2022/12/20 01:57, Darrick J. Wong wrote: > > On Fri, Dec 16, 2022 at 03:05:43PM +0800, Qu Wenruo wrote: > > > Although "testcase" tags contain the "timestamp" element, for day-0 > > > testing it can be hard to relate the timestamp to the tested kernel > > > version. > > > > > > Thus this patch will add a "kernel" element to the "testcase" tag, to > > > indicate the kernel version we're running. > > > Paired with CONFIG_LOCALVERSION_AUTO=y config, it will easily show the > > > kernel commit we're testing. > > > > > > Since we're here, also add a "arch" element, as there are more and more > > > aarch64 boards (From RK3399 to Apple M1) able to finish fstests in an > > > acceptable duration, we can no longer assume x86_64 as our only > > > platform. > > > > > > Signed-off-by: Qu Wenruo <wqu@suse.com> > > > --- > > > common/report | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/common/report b/common/report > > > index 4a747f8d..92586527 100644 > > > --- a/common/report > > > +++ b/common/report > > > @@ -49,7 +49,7 @@ _xunit_make_section_report() > > > date_time=$(date +"%F %T") > > > fi > > > local stats="failures=\"$bad_count\" skipped=\"$notrun_count\" tests=\"$tests_count\" time=\"$sect_time\"" > > > - local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" " > > > + local hw_info="hostname=\"$HOST\" timestamp=\"${date_time/ /T}\" arch=\"$(uname -m)\" kernel=\"$(uname -r)\"" > > > echo "<testsuite name=\"xfstests\" $stats $hw_info >" >> $REPORT_DIR/result.xml > > > > The original commit that added this report format was f9fde7db2f > > ("report: Add xunit format report generator"). Dmitry Monakhov's commit > > message points out that the xml being emitted was "xunit/junit": > > > > Footnotes: > > [1] https://xunit.github.io/docs/format-xml-v2.html > > [2] http://help.catchsoftware.com/display/ET/JUnit+Format > > > > The first link is now dead, but the second link contains enough > > information to find the current junit xml format: > > > > [1] https://raw.githubusercontent.com/windyroad/JUnit-Schema/master/JUnit.xsd > > > > Note that the xunit project appears to have diverged their report > > format: > > > > [2] https://xunit.net/docs/format-xml-v2 > > Great we have something solid to follow. > > > > > (Or perhaps there were multiple things called xunit?) > > > > Either way, it's pretty obvious from common/report code that the "xunit" > > code is still emitting junit xml files. I think it's important that > > fstests should continue to follow that schema, so that these files can > > be fed into test dashboards (yes I have one) that consume this file > > format. > Totally agreed. > > > > > Regrettably, the schema does not provide for @arch or @kernel attributes > > hanging off the <testsuite> element, so it's not a good idea to add > > things that a strict parser could reject. > > I'm totally fine with the properties method, but still curious why some > parsers would even reject elements with unknown attributes? > > Isn't the idea of XML (or JSON) to be flex for newer attributes? Yes, and the idea of xml schemas is to declare exactly what we're going to spit out, and in a format where automated tools can hold us to what we've promised. :) Note that xml allows for namespaced elements. If we ever want to extend the format by adding our own elements, we prefix them with our own namespace and the validation tools won't trip over them. Though in the end I found enough bugs in the junit xml specification that I decided it'd be easier to create a new schema file that reflects exactly what common/report creates. > > > > That said, I think it's important to record the architecture and kernel. > > Probably even more attributes than that. The junit xml schema provides > > for arbitrary string properties to be attached to reports; would you > > mind putting these there instead? > > > > (I want to add a few more properties now that people have started > > talking about reporting again... ;)) > > > > # Properties > > echo -e "\t<properties>" >> $REPORT_DIR/result.xml > > echo -e "\t\t<property name=\"arch\" value=\"$(uname -m)\"/>" >> $REPORT_DIR/result.xml > > echo -e "\t\t<property name=\"kernel\" value=\"$(uname -r)\"/>" >> $REPORT_DIR/result.xml > > for p in "${REPORT_ENV_LIST[@]}"; do > > _xunit_add_property "$p" > > done > > echo -e "\t</properties>" >> $REPORT_DIR/result.xml > > Sounds pretty good, thanks for all the awesome advices! I spent the day working on exporting a lot more test machine config elements, so please have a look at the RFC series that I'm going to send in a little bit. --D > Qu > > > > > --D > > > > > # Properties > > > -- > > > 2.38.0 > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] fstests: report: add arch and kernel version info into testsuite attributes 2022-12-19 23:48 ` Darrick J. Wong @ 2022-12-20 0:00 ` Theodore Ts'o 0 siblings, 0 replies; 5+ messages in thread From: Theodore Ts'o @ 2022-12-20 0:00 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Qu Wenruo, Qu Wenruo, linux-btrfs, fstests For what it's worth, here is how I add properties to the xunit file. I do it after the fact using a tiny python script: https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/usr/local/bin/update_properties_xunit This way I can dump a lot of interesting information about the test run into the XML file. (See attached for the beginning of a results.xml file generated by gce-xfstests.) I also have a handy script which allows me to run separate file system configs in separate VM's, and then combine the xunuit files together: https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/usr/local/bin/merge_xunit https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/usr/local/bin/combine_xunit I'm a **big** fan of this approach, since it allows me to take about 24 hours worth of test runs, shard them across 12 different VM's, so that it akes about 2.5 hours of wall clock time to do a full ext4 test run. After all, cloud VM time is cheap; software engineering time is expensive. :-) - Ted <?xml version="1.0" encoding="utf-8"?> <testsuite name="xfstests" failures="6" skipped="160" tests="1045" time="14724" hostname="xfstests-ltm- 20220825074228-aa" timestamp="2022-08-25T11:55:34"> <properties> <property name="CMDLINE" value="--instance-name xfstests-ltm-20220825074228-aa --gce-zo ne us-west1-a --gs-bucket gce-xfstests --kernel gs://gce-xfstests/kernel.deb --bucket-subdir results -- no-email -c xfs/4k -g auto --local-ssd-nvme --image-project gce-xfstests"/> <property name="FSTESTIMG" value="gce-xfstests/xfstests-202208242313"/> <property name="FSTESTPRJ" value="gce-xfstests"/> <property name="KERNEL" value="kernel 6.0.0-rc2-xfstests #756 SMP PREEMPT_DYNAMIC Mon Aug 22 22:04:33 EDT 2022 x86_64"/> <property name="FSTESTVER" value="blktests 4e07b0c (Fri, 15 Jul 2022 14:40:03 +090 0)"/> <property name="FSTESTVER" value="fio fio-3.31 (Tue, 9 Aug 2022 14:41:25 -060 0)"/> <property name="FSTESTVER" value="fsverity v1.5 (Sun, 6 Feb 2022 10:59:13 -0800)"/ > <property name="FSTESTVER" value="ima-evm-utils v1.3.2 (Wed, 28 Oct 2020 13:18:08 -0400 )"/> <property name="FSTESTVER" value="nvme-cli v1.16 (Thu, 11 Nov 2021 13:09:06 -0800) "/> <property name="FSTESTVER" value="quota v4.05-43-gd2256ac (Fri, 17 Sep 2021 14: 04:16 +0200)"/> <property name="FSTESTVER" value="util-linux v2.38.1 (Thu, 4 Aug 2022 11:06:21 +0200 )"/> <property name="FSTESTVER" value="xfsprogs v5.19.0 (Fri, 12 Aug 2022 13:45:01 -050 0)"/> <property name="FSTESTVER" value="xfstests-bld bb566bcf (Wed, 24 Aug 2022 23:07:24 -04 00)"/> <property name="FSTESTVER" value="xfstests v2022.08.21-8-g289f50f8b (Sun, 21 Aug 2 022 15:21:34 -0400)"/> <property name="FSTESTVER" value="zz_build-distro bullseye"/> <property name="FSTESTCFG" value="xfs/4k"/> <property name="FSTESTSET" value="-g auto"/> <property name="FSTESTEXC" value=""/> <property name="FSTESTOPT" value="aex"/> <property name="MNTOPTS" value=""/> <property name="CPUS" value="2"/> <property name="MEM" value="7680"/> <property name="DMI_MEM" value="7680 MB (Max capacity)"/> <property name="GCE ID" value="8073487017178750853"/> <property name="MACHINE TYPE" value="n1-standard-2"/> <property name="TESTRUNID" value="ltm-20220825074228-aa"/> <property name="TESTCFG" value="xfs/4k"/> </properties> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-12-20 0:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-12-16 7:05 [PATCH] fstests: report: add arch and kernel version info into testsuite attributes Qu Wenruo 2022-12-19 17:57 ` Darrick J. Wong 2022-12-19 22:30 ` Qu Wenruo 2022-12-19 23:48 ` Darrick J. Wong 2022-12-20 0:00 ` Theodore Ts'o
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox