canonical-ci-engineering team mailing list archive

[Francis Ginther <francis.ginther@xxxxxxxxxxxxx>]

Kevin,

We've start testing the configuration changes necessary to meet your
priority 1 goals and have created jobs for:

* wily armhf (any real phone hw)
* wily i386

Both of these configurations are failing tests while building lp:mir

* http://s-jenkins.ubuntu-ci:8080/job/mir-wily-i386-ci/1/
* http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-builder-wily-armhf/2/

Before enabling these for CI and autolanding, do you want to get the tests
passing first? We can add these builds to the current mir-ci and
mir-autolanding jobs such that they don't directly impact the outcome of
the overall MP, but do get listed in the results so that these failures can
be addressed without blocking other work. A side effect of doing this is
that the overall test time would take about 1.5 hours longer.

Please let us know what you'd like to do.

Francis

On Tue, Aug 18, 2015 at 4:19 PM, Francis Ginther <
francis.ginther@xxxxxxxxxxxxx> wrote:

> Forwarding this on to the wider CI team -
> canonical-ci-engineering@xxxxxxxxxxxxxxxxxxx
>
> On a first look, most of these appear to be doable via job configuration
> changes. And as you pointed out a couple of the jobs are mislabled or
> misconfigured (kdub identified that the current phone test is building
> vivid packages, but installing on a wily image, this needs to be fixed). I
> expect we can get this problems addressed first and start moving on to
> these other updates.
>
> Francis
>
> On Tue, Aug 18, 2015 at 1:46 PM, Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx>
> wrote:
>
>> Hey Francis -
>> I wanted to start a conversation with you as I think you might already be
>> chasing some of this and you're probably the right person.
>> So it dawned on me through the ci hiccups from gcc5 transition, that what
>> we would want in an ideal world is projects tested on all supported
>> platforms/archives with some relative priority attached.
>> Meaning for example....
>> #1 priorities - really should never be broken
>> vivid+overlay armhf (any real phone hw)
>> wily armhf (any real phone hw)
>> wily i386
>> wily amd64
>>
>> #2 priorities - should warn if broken
>> wily arm64
>> vivid on amd64
>> vivid on i386
>>
>> #3 proiorities - nice to have
>> vivid on armhf (not necessarily phone hw)
>>
>> I think at the moment there are projects like unity8 & mir that are only
>> using wily - so no vivid+overlay coverage. Which is really not good for our
>> desire and push for quality on phone programs. When we were dual landing
>> and wily & vivid+o were very close then no problem....but the toolchain
>> alone now is good reason to address this. NOTE: also mir jobs are still
>> labled "vivid" even thot they're using wily (which i'm guessing you've
>> probably noticed)
>>
>> At any rate I'm raising this because I think not only my team's projects
>> but the wider org should all be following the outline above. e.g. teams
>> belonging to bfiller, dbarth, bzoltan, etc
>>
>> Let me know what you think.
>> Also, let me know if we can mix archive targets within a project ci ? I
>> would suppose it would be up to the job definition - so i would think we
>> can do this.
>>
>> And I hate to be this way, but that lack of coverage for vivid+o is to me
>> so concerning I feel like we need to address this asap (even tho self
>> service ci may be coming, i think not quick enough to make sure we close
>> this gap)
>> Also, I am happy for my teams to help with proj ci job management if
>> needed...i would think other teams would be as well.
>>
>> br,kg
>>
>
>
>
> --
> Francis Ginther
> Canonical - Ubuntu Engineering - Continuous Integration Team
>



-- 
Francis Ginther
Canonical - Ubuntu Engineering - Continuous Integration Team