← Back to team overview

canonical-ci-engineering team mailing list archive

Re: Question about moving the memevent tests wrt: dep8

 

After talking to Chris on IRC, I got the impression I need to expand on my
suggestion a bit.  What I'm suggesting is one of 2 processes. It doesn't
really matter much to me, but QA might have a preference for one over the
other.

Basically, adt-run can run with an unbuilt tree. The unbuilt tree just
needs a very stripped down control file and debian/tests bits.
example:
    adt-run -o /tmp/adtout -B --unbuilt-tree /tmp/scratch/adt/settle ---
ssh -d -s adb
So we can still keep these tests in our "tests" directory under
lp:ubuntu-test-cases/touch

Option 1: You can develop your tests against lp:ubuntu-test-cases/touch,
and submit tests (and patches to tests) as normal MPs
Option 2: You can develop your tests in another project for longer-running
development with more iterations, and when you're happy with the state of
things, periodically ask us to pull a certain revision or tag into our
tree. This way you can keep going with development in a trunk branch, while
we keep a stable version for running in daily smoke testing.

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

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

Follow ups

References