canonical-ci-engineering team mailing list archive

[Chris Lee <chris.lee@xxxxxxxxxxxxx>]

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
>