show summary at end of log file

Bug #1484991 reported by Barry Warsaw
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
autopkgtest (Ubuntu)
Fix Released
Wishlist
Martin Pitt

Bug Description

Very often, it's quite difficult to find all the results in the log files. If there's a lot of output between runs of separate tests, the results can be separated by a lot of output. Further, there's no super great way to search for the results.

Better would be something like Python's unittest suite where all failure results are captured and printed at the end of the run. At least that way, all you'd need to do is scroll to the bottom of the log file and see all failures.

Related branches

Revision history for this message
Martin Pitt (pitti) wrote :

Indeed the single "log" often isn't the easiest to consume output. But every individual test has its own <testname>-stdout and <testname>-stderr artifact, which is also available from http://autopkgtest.ubuntu.com ("artifacts.tar.gz" link). stderr and exit codes are also contained in the "summary" file (also in artifacts.tar.gz). Is that more suitable for you? If not, how would you propose to do that in a better way?

As autopkgtest can't interpret the contents of that there isn't that much more that we can do beyond that. I. e. the actual test output is just a blob from autopkgtest's view.

Revision history for this message
Barry Warsaw (barry) wrote : Re: [Bug 1484991] Re: Too hard to find results in the log files

On Aug 14, 2015, at 03:19 PM, Martin Pitt wrote:

>Indeed the single "log" often isn't the easiest to consume output. But
>every individual test has its own <testname>-stdout and
><testname>-stderr artifact, which is also available from
>http://autopkgtest.ubuntu.com ("artifacts.tar.gz" link). stderr and exit
>codes are also contained in the "summary" file (also in
>artifacts.tar.gz). Is that more suitable for you? If not, how would you
>propose to do that in a better way?

Ah, good to know! Maybe instead of putting those only in the artifacts
tarball, they could be unpacked and linked from the autopkgtests.ubuntu.com
page?

>As autopkgtest can't interpret the contents of that there isn't that
>much more that we can do beyond that. I. e. the actual test output is
>just a blob from autopkgtest's view.

But the final PASS/FAIL results and exit codes are available to autopkgtest,
right? Maybe just a summary at the end could be printed with that
information?

Revision history for this message
Martin Pitt (pitti) wrote : Re: Too hard to find results in the log files

Printing the summary at the end of logs indeed does sound like a good improvement, especially if a package has several tests and not the last one failed. I usually search for "- - results" in logs to jump between the test results, but this might be more obvious with a final summary.

Moving summary from artifacts.tar.gz to result.tar seems okay, but not sure if that's still needed once log.gz gets the summary too?

Changed in autopkgtest (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
summary: - Too hard to find results in the log files
+ show summary at end of log file
Changed in autopkgtest (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Revision history for this message
Martin Pitt (pitti) wrote :
Changed in autopkgtest (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package autopkgtest - 3.16.3

---------------
autopkgtest (3.16.3) unstable; urgency=medium

  * adt-setup-vm: Use /etc/cloud.cfg.d/ to avoid conffile prompts on upgrades.
    (LP: #1477626)
  * Don't invoke QEMU with -localtime. QEMU defaults to and Linux prefers the
    hw clock in UTC. This avoids large time jumps when doing NTP.
  * adt-setup-vm: Start autopkgtest shell after all other SysV init
    scripts/facilities, to avoid a too early start of tests while boot is
    still in progress.
  * doc/README.package-tests.rst: Use comma separator in examples.
  * VirtSubproc.check_exec(): Actually error out on stderr as documented.
  * adt-virt-ssh: Verify that sudo does not write errors, as that
    interferes with auxverbs and generally is a sign of host mis-configuration
    (typically wrong hostname).
  * ssh-setup-nova: Set hostname to "adt". This avoids overly long host names
    from defaulting to nova instance names (which can be very long).
  * ssh-setup/nova: Fix parsing of IP address from "nova show" to avoid
    tripping over instance names containing "network". (LP: #1481574)
  * Fix error message and code for "invalid test depends" errors.
  * tests/pep8: Ignore E402 ("module level import not at top of file"), as
    that's impossible to satisfy; we have to set sys.path before.
  * ssh-setup/nova: In cleanup(), wait until the instance gets deleted. This
    avoids name collisions and instance quota overflow.
  * adt-run: Always show summary at the end, which is particularly helpful for
    multiple tests. (LP: #1484991)
  * adt-run.1: Clarify that without any logging options adt-run only logs to
    stderr. (LP: #1485661)
  * adt-virt-lxc: If the executed command exits with 255, translate that to
    253 in the auxverb wrapper, as 255 is the exit code for failures of the
    auxverb itself. This avoids considering ordinary test failures as
    temporary testbed failures.
  * adt-run: Show host name, to more easily identify hosts with frequent
    failures.
  * adt-virt-lxc: Always call lxc-stop with --kill, as the containers are not
    precious and normal shutdown might hang.
  * adt-virt-lxc: In cleanup, stop LXC container before removing the shared
    downtmp, to ensure that we always clean up the running container. Also
    don't fail on errors. (LP: #1488879)
  * ssh-setup/nova: Add missing apt sources for -updates/-security
    restricted/multiverse pockets.

 -- Martin Pitt <email address hidden> Thu, 27 Aug 2015 19:54:51 +0200

Changed in autopkgtest (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.