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