I've raised https://issues.apache.org/jira/browse/INFRA-4853 to cover the fact that our build have stopped automatically running. That leaves the following test failures as open issues:
org.apache.aries.application.runtime.itests.IsolatedCfgAdminRuntimeTest.testIsolatedCfgAdminBPReload [equinox/3.5.0] org.apache.aries.application.runtime.itests.IsolatedRuntimeTest.testFrameworkResolvedBeforeInnerBundlesStart [equinox/3.5.0] org.apache.aries.application.runtime.itests.UpdateAppTest.testUpdateThenStart [equinox/3.5.0] org.apache.aries.application.runtime.itests.MinimumImportsTest.testAppUsingAriesApplicationManager [equinox/3.5.0] org.apache.aries.application.runtime.itests.OBRResolverAdvancedTest.testRepo [equinox/3.5.0] org.apache.aries.application.runtime.itests.OBRResolverAdvancedTest.testRepoAgain [equinox/3.5.0] org.apache.aries.jndi.itests.JndiUrlIntegrationTest.testBlueprintCompNamespaceWorks [equinox/3.5.0] org.apache.aries.samples.blog.itests.QuiesceBlogSampleWithEbaTest.test [equinox/3.5.0] org.apache.aries.samples.blog.itests.JdbcBlogSampleWithEbaTest.test [equinox/3.5.0] org.apache.aries.samples.blog.itests.JpaBlogSampleWithEbaTest.test [equinox/3.5.0] org.apache.aries.sample.twitter.itest.TwitterTest.testTwitter [equinox/3.5.0] org.apache.aries.transaction.itests.InvalidTranAttributeTest.testInvalid [equinox/3.7.0.v20110613] org.apache.aries.transaction.itests.NotSupportedTranAttributeTest.testNotSupported [equinox/3.7.0.v20110613] The regressions seem to have been triggered by changes on the following work items: [ARIES-663] Fix problems with JMX mbeans registration / unregistration [ARIES-846] The Aries transaction manager does not recover transactions correctly [ARIES-809] Allow the transaction manager to be created when there's no specific configuration and two Blueprint changes with no associated work item. Holly On Fri, May 25, 2012 at 1:44 PM, Holly Cummins <[email protected]> wrote: > It looks like we have a few other build issues as well. They got worse after > breaking on Monday, so by Wednesday we had fifty five test failures. Then, > on Thursday, the subversion polling seems to have stopped polling. > > I've kicked an 'Aries' build off, to see if the latest fixes for ARIES-851 > improved things, and it's looking a bit healthier, but there are still lots > of failures. > > Sent from my iPhone > > > On 25 May 2012, at 13:27, Jeremy Hughes <[email protected]> wrote: > >> On 25 May 2012 13:18, Jeremy Hughes <[email protected]> wrote: >>> >>> On 25 May 2012 12:45, Holly Cummins <[email protected]> >>> wrote: >>>> >>>> >>>> On 25 May 2012, at 12:21, Christian Schneider <[email protected]> >>>> wrote: >>>> >>>>> While I was able to fix my local build by building aries by hand it >>>>> does >>>>> not help the jenkins build : >>>>> >>>>> https://builds.apache.org/view/G-L/view/Karaf/job/Karaf/1215/ >>>> >>>> >>>> >>>> That build seems to be using dated snapshots for the parent. I wonder >>>> why? I >>>> think that's unlikely to work, unless we deploy every possible snapshot. >>>> I'll investigate and see if I can figure out where the date came from. >>>> >>>> >>>>> >>>>> It seems like the Aries build also fails with some rather >>>>> infrastructure >>>>> like looking exception. >>>>> >>>> >>>> Hmm. The main Aries build had been working until Monday, and I think the >>>> current failures (which hopefully are about to go away) are test >>>> related. Is >>>> it the Aries deploy build you're looking at? That's the one which feeds >>>> the >>>> Karaf build, and it is pretty dead. Its failure seems infrastructure-ish >>>> but >>>> not parent-related. >>> >>> >>> In the console output for the latest Aries - Deploy build, at the end >>> there are these lines: >>> [INFO] Retrieving previous build number from apache.snapshots.https >>> Uploading: >>> https://repository.apache.org/content/repositories/snapshots/org/apache/aries/quiesce/org.apache.aries.quiesce.manager.itest/1.0.0-SNAPSHOT/org.apache.aries.quiesce.manager.itest-1.0.0-20120524.034135-11-sources.jar >>> 4K uploaded >>> (org.apache.aries.quiesce.manager.itest-1.0.0-20120524.034135-11-sources.jar) >>> Build timed out (after 60 minutes). Marking the build as failed. >>> >>> Indeed the time the build took to fail was 59 mins 13 secs. So there >>> must be a config param that is saying fail after 60 mins whatever >>> you're doing. >>> >>> Does anyone know why it's set to fail whatever after 60 mins? I'll >>> hunt down the config parm in the meantime. >> >> >> It might be those pesky Quiesce tests taking a long time to complete. >> In this case it seems they just completed within the hour, then the 60 >> mins timer kicked in. The build on 23May also timed out but later on >> during the ariestrader sample. The 22May build failed during the >> twitter sample. So, I'm going to extend the timer to 120 mins so we >> can get a clean build. Of course we should look to see what is really >> slowing things down - the amount of extra time required seems to be >> very variable. I might have a chance to look later, but if anyone >> wants to look, please feel free. >> >>> >>>> >>>> >>>>> Any idea how we can get this working again? >>>>> >>>> >>>> Once the Aries build is green again I'm planning to deliver ARIES-853, >>>> which >>>> switches to using non-snapshot parents. This should make everything >>>> work, >>>> but only until the next project switches to using a snapshot parent. >>>> >>>> Holly >>>> >>>> >>>>> Christian >>>>> >>>>> >>>>> Am 25.05.2012 11:06, schrieb Holly Cummins: >>>>>> >>>>>> >>>>>> The parent snapshot should currently be deployed to a snapshot >>>>>> repository, but it looks like maybe that's not being found in your >>>>>> case. >>>>>> Building the parent project first should get things working for you. >>>>>> >>>>>> Holly >>>>>> >>>>> >>>>> -- >>>>> Christian Schneider >>>>> http://www.liquid-reality.de >>>>> >>>>> Open Source Architect >>>>> Talend Application Integration Division http://www.talend.com >>>>> >>>> >
