canonical-ci-engineering team mailing list archive

[Chris Lee <chris.lee@xxxxxxxxxxxxx>]

Awesome, thanks for the clarification Paul.

Regards,
Chris

On Wed, Nov 5, 2014 at 4:10 PM, Paul Larson <paul.larson@xxxxxxxxxxxxx>
wrote:

> 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
>>>
>>
>>
>