Thomi, NIcholas and I discussed these failures last week and some options for debugging. The first step is to create some infrastructure to run all of the core-apps jobs en masse to more easily identify which ones are regularly failing and provide a means to do more systematic regression testing of changes to the jobs themselves. Then it's just the process of looking at the specific failures.
Is there a specific priority to this work or is it part of a bigger goal? I expect to have the infrastructure in place this week to collect the failures and perform regression testing. Anything beyond that depends on the failures encountered. Francis On Thu, Sep 18, 2014 at 4:43 PM, Thomi Richards < [email protected]> wrote: > Hi, > > On Fri, Sep 19, 2014 at 2:52 AM, Nicholas Skaggs < > [email protected]> wrote: > >> At the moment, clock autolands on the device, but nothing else does. The >> straightforward job changes resulted in the tests failing, not running etc >> so they were not enabled. It's unclear why this is occurring inside jenkins >> and will take some effort for each application to diagnose. The failures >> themselves seemed related to infrastructure and not actual test failures, >> though there are some actual test failures as well I'm sure. >> >> Switching to autolanding on devices with test failures results in MP's >> piling up and not landing; the jobs need to work before we can enable them. >> > > That seems fair to me. Can someone from CI comment on this please? > > Cheers, > > > -- > Thomi Richards > [email protected] > -- 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
