On Tue, Sep 8, 2015 at 5:14 PM, Cemil Azizoglu <[email protected] > wrote:
> > On Tue, Sep 8, 2015 at 4:58 PM, Kevin Gunn <[email protected]> > 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 < >> [email protected]> 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 < >>> [email protected]> wrote: >>> >>>> Forwarding this on to the wider CI team - >>>> [email protected] >>>> >>>> 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 <[email protected]> >>>> 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
-- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
