canonical-ci-engineering team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

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/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

> 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

Attachment: signature.asc
Description: Digital signature