Hi Francis, On Thu, Dec 11, 2014 at 02:38:30PM -0600, Francis Ginther wrote: > Can you provide some additional context around what this test needs? What > requirements does the test-suite have on the framework that would execute > it? I've made some high-level assumptions that it requires:
> - Access to an adb capable device. > - Access to adb or something similar to reboot, push, pull, etc. > - Control over the provisioning of the device or access to > ubuntu-device-flash itself. > - The ability to execute multiple test cases while the device under test > goes through reboots, image updates and flashing of the device. > I'm sure I've missed lots of details, but are there any other significant > requirements or did miss the mark with those above? I don't think there are any other requirements. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected] > On Thu, Dec 11, 2014 at 10:42 AM, Martin Pitt <[email protected]> > wrote: > > > 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) > > > > > > -- > Francis Ginther > Canonical - Ubuntu Engineering - Continuous Integration Team
signature.asc
Description: Digital signature
-- 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
