Source: autopkgtest
Version: 5.26
Severity: important
Whenever I upload a package, I use my build automation tool, vectis[1] to
build it in sbuild and run autopkgtests, piuparts and lintian, because I'm
doing my best to avoid uploading something that has serious regressions.
In previous releases this took about 2h35, which is already inconveniently
long. For the 5.26 release, it took 5h31, which is just unsustainable - I
can't do releases if they're going to take most of a day per attempt.
A breakdown of the time to run autopkgtest's autopkgtests in a qemu VM,
excluding time taken to install dependencies:
- autopkgtest (NullRunner, ChrootRunner, etc.): 3 minutes
- installed (a smoke-test): < 1 minute
- docker: 32 minutes
- lxc: 16 minutes
- lxd: 45 minutes
- podman: 41 minutes
- podman-init: 20 minutes
- schroot: 96 minutes (!)
- unshare: 9 minutes
I don't know why schroot was so painfully slow. I already made changes
during this release cycle to try to speed it up.
I want to see whether we can run the unshare test (currently marked with
isolation-machine) in lxc containers like the ones used by debci. If we
can, then I'm inclined to use UnshareRunner for all the test coverage
that can't be done by NullRunner or ChrootRunner, use lxc or podman-init
for all the test coverage that needs an init system, and limit docker,
lxd, podman and schroot to a relatively simple smoke-test (plus targeted
tests for things that are known to have regressed for those backends).
smcv
[1] https://salsa.debian.org/smcv/vectis
