Another way to iterate on these test failures is to manually run the new jobs on a bzr branch. Developers should have access to build these two jobs, specifying their branch as the "landing_candidate", then watching for the results (they will *not* be automatically posted to the MP).
http://s-jenkins.ubuntu-ci:8080/job/mir-wily-i386-ci/ http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-wily-touch/ Only the "landing_candidate" parameter needs to be supplied. All other parameters can be left at the default value. Francis On Wed, Sep 9, 2015 at 2:28 PM, Francis Ginther < [email protected]> wrote: > Let me clarify that 1.5 hour time increase. That only applies if you want > to run these new builds as 'advisory' or not impacting the final result of > the build. The reason for the long time in this case is that jenkins has to > run the 'must-pass' jobs first and then the 'advisory' builds serially. In > my proposal above, the "wily armhf (any real phone hw)" and "wily i386" > jobs would be advisory. I only proposed this as a solution to addressing > the currently broken tests without blocking unrelated MPs that would fail > if the tests were just turned on as 'must-pass'. > > If all of these jobs are 'must-pass' then they can all be executed > concurrently and build times would be the same as they are today assuming > nothing else is building and nothing has to wait for resources. > > Francis > > On Tue, Sep 8, 2015 at 5:26 PM, Stephen M. Webb < > [email protected]> wrote: > >> On 15-09-08 05:58 PM, Kevin Gunn 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 >> > >> > 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 >> >> I'd really rather see everything thrown at the MP CI so failures just >> don't make it as far as the archive. Promotion to >> release is not the time to start finding problems, that's the entire >> point of CI at the MP level. >> >> Why would the builds be slowed down so much? Is it just that the >> hardware is slow or is there a long delay waiting for >> resources in general? >> >> -- >> Stephen M. Webb <[email protected]> >> > > > > -- > 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
