canonical-ci-engineering team mailing list archive

[Paul Larson <paul.larson@xxxxxxxxxxxxx>]

adt-run, when used on the touch image, handles unlocking the device for
you. We will make sure the device is provisioned in advance.

On Tue, Nov 4, 2014 at 3:12 PM, Chris Lee <chris.lee@xxxxxxxxxxxxx> wrote:

> Thanks for the clarification Paul.
>
> A follow on discussion about Utah and its replacement, can we confirm the
> environment for the dep8 tests that will be run?
> Namely we are interested in wherever the device will be provisioned and
> the screen unlocked so that any tests can run unhindered.
>
> QA team, am I missing anything else that we need to confirm?
>
>
> Chris
>
> On Tue, Nov 4, 2014 at 6:09 PM, Paul Larson <paul.larson@xxxxxxxxxxxxx>
> wrote:
>
>> On Mon, Nov 3, 2014 at 9:18 PM, Chris Lee <chris.lee@xxxxxxxxxxxxx>
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm working on the memevent tests that can be found in
>>> lp:ubuntu-test-cases/touch[1].
>>> One of the tasks is to make it dep8 compliant and I have a couple of
>>> questions regarding the best way forward.
>>>
>>>  1. Would you prefer if I move the memevent tests out into it's own
>>> branch to make the dep8 stuff easier to handle? Or do you prefer keeping it
>>> under the ubuntu-test-cases/touch branch?
>>>
>> We don't have an existing precedent for this, but here are my thoughts.
>> I like the idea of having tests that other teams maintain in a separate
>> branch, because it gives you full control over what goes into it. BUT, we
>> also don't want to have changes creeping into the CI runs without any idea
>> where they came from. So what I would propose, is that for now you develop
>> in a separate branch, and we pull the contents of that branch into
>> ubuntu-test-cases when we're ready to run the adt version. When you have an
>> update, you tell us to pull and we do a quick test to make sure it still
>> behaves and doesn't exhibit some strange new behavior, and then pull it
>> in.  Otherwise, if you want to keep everything against our trunk, MPs
>> against that are fine as well.
>>
>>
>>>   2. Are the Utah setup files still needed or, due to it being dep8, is
>>> this no longer needed and the provisioning sorted out elsewhere?
>>>
>> No, assume utah will no longer be used at all.  The one piece that may
>> linger for a short while is the yaml results format since the dashboard
>> consumes that. We already have a script that can take the junitxml that we
>> convert from subunit, and convert that to yaml though, so there's nothing
>> you need to do there.  Once the dashboard speaks subunit, there won't even
>> be a need for that.
>>
>> Thanks for working on this!
>> - Paul Larson
>>
>
>