Bug#741322: autopkgtest: responds poorly to timeout, should display stdout/stderr and move on
Simon McVittie [2014-03-11 9:36 +0000]:
> However, from the output that was logged, I can't tell what the difference
> or failure was, because adt-run logged the extensive shell command that it
> invoked, but not any of its output.
> > adt-run: version 2.7.2
This version on ci.debian.net is indeed a bit old. Version 2.9 learned
to provide live output for schroot and LXC, so you would actually see
what the test was doing until then. Antonio, is it possible to update
autopkgtest on ci.debian.net? I'm uploading 2.9.2 today which fixes a
regression from 2.9 that broke python-apt, otherwise that one should
be good (FTR, I'm running autopkgtest from git in Ubuntu's production
So this part of the issue should already be fixed on the autopkgtest
> It also aborted the entire test run when the timeout was reached,
> rather than moving on to the next autopkgtest (admittedly, dbus only
> has two, because I'm representing all the upstream tests as one big
> autopkgtest at the moment, but it was the first one that failed).
Good point. Keeping this report for that issue.
> As it happens, all the current dbus installed-tests are meant to be
> fast (< 1 minute), so for the next upload I'm going to wrap each test in
> coreutils timeout(1) and see what happens; but it seems wrong to be
> second-guessing adt-run's own timeout logic?
The default test timeout is 10.000 seconds (2.7 hours), so it's still
friendlier towards the CI infrastructure to self-impose significantly
shorter timeouts. At the moment you can change the timeouts on calling
adt-run, but tests themselves can't do that declaratively in
debian/control. (Another thing to consider, and allow tests to set
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature