canonical-ci-engineering team mailing list archive

[Cemil Azizoglu <cemil.azizoglu@xxxxxxxxxxxxx>]

On Tue, Sep 8, 2015 at 5:14 PM, Cemil Azizoglu <cemil.azizoglu@xxxxxxxxxxxxx
> wrote:

>
> On Tue, Sep 8, 2015 at 4:58 PM, Kevin Gunn <kevin.gunn@xxxxxxxxxxxxx>
> wrote:
>
>> 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
>>
>>
> ​Discovering issues during release is never fun. I'm wondering if we could
> just run the new configs during autolanding only, which normally happens
> once per MP. And then during release we can run all priority 1 configs as
> you suggested.
>


Oh and ​Also, once Jenkaas is deployed we can experiment and eventually
have all the configs running on MPs.
​


> ​
>
>
>> 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
>>>
>>
>>
>
>
> --
> Cemil Azizoglu
> Mir Display Server - Team Lead
> Canonical USA
>



-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA