Hello, Francis Ginther [2014-12-10 22:36 -0600]: > My first thought is to extend autopkgtest with a new flavor of testbed that > provides a container to run the tests and command-hooks into a slave > device. The hooks provide some basic set of interfaces to interact with the > slave device: push, pull, reboot, execute, etc. (the command set provided > by adb comes to mind).
That's exactly what the ssh runner setup scripts are. (Documented in man adt-virt-ssh). This could probably take the existing adb script and modify it. > autopkgtest would then execute the tests inside the container and > provide the backend to fulfill the slave command interface. I would > consider this a new dep8 restriction, 'isolation-slave' or > something. I need to think about it, but this could work: virt runners (like qemu, lxc, schroot, ssh) can export capabilities, and ssh setup script can export them; right now these are a fixed set, but we could do some x-anything which you can then check in Restrictions:. But again, this is mostly cosmetical, for local runs; the main difference is that with that you limit a test to only one possible testbed and SKIP everywhere else (and you can't even try it on other testbeds), while without this stuff you'd get a failure; unless you prepared your other testbed to look similar enough to your real target platform. Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
