canonical-ci-engineering team mailing list archive

[Francis Ginther <francis.ginther@xxxxxxxxxxxxx>]

Steve,

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?

Thanks,
Francis

On Thu, Dec 11, 2014 at 10:42 AM, Martin Pitt <martin.pitt@xxxxxxxxxx>
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