canonical-ci-engineering team mailing list archive

[Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx>]

Whoa! 1.5 hrs longer.
Per MP that'd probably be too painful as wait times have been an issue in
the past, especially for Mir (not sure what we're down to, but i think it
was ~30min at best).

Wondering (wanting Cemil/Stephen to chime in) would it make sense to have
all MP's landing on development-branch running CI on
* vivid+overlay armhf (any real phone hw)
* wily amd64

Then have promotions to release run on all the priority 1 configurations
* vivid+overlay armhf (any real phone hw)
* wily amd64
* wily armhf (any real phone hw)
* wily i386

in order to avoid sinking so much time into every MP

br,kg



On Tue, Sep 8, 2015 at 4:30 PM, Francis Ginther <
francis.ginther@xxxxxxxxxxxxx> wrote:

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