canonical-ci-engineering team mailing list archive

[Francis Ginther <francis.ginther@xxxxxxxxxxxxx>]

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 <
francis.ginther@xxxxxxxxxxxxx> 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 <
> stephen.webb@xxxxxxxxxxxxx> 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  <stephen.webb@xxxxxxxxxxxxx>
>>
>
>
>
> --
> Francis Ginther
> Canonical - Ubuntu Engineering - Continuous Integration Team
>



-- 
Francis Ginther
Canonical - Ubuntu Engineering - Continuous Integration Team