Thanks Francis - I'll leave it up to Stephen how he wants it, advisory or must-pass
On Thu, Sep 10, 2015 at 9:21 AM, Francis Ginther < [email protected]> wrote: > 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
