Hi Lewis, for the Jenkis part it's my fault *blush* just let me find a cycle of 15 minutes (unfortunately I cannot work fulltime on OSS activities) and I'll adjust the build!
best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Mar 7, 2012 at 12:49 PM, Lewis John Mcgibbney <[email protected]> wrote: > Hi Guys, > > As the title suggests, the nightly CI's appear to have been stricken by a > phantom illness as of late. > > Having taken a bit of time this morning to look into this, I see the > following > > - From ages ago, build output somehow indicates that after building every > module, Jenkins tries to build at least every module again and again! The > only log output to support this is "(didn't run)", which is not correct as > build output specifies that modules did run and that they built > successfully. > - #119, 120 & 122; the first and third failed due to the dratted > "hudson.util.IOException2" we witness occur periodically on the the > Solaris/Ubuntu slaves. Although these are not welcomed, they cannot be > attributed to Any23 as a project and it looks like we just need to live > with them. The middle was a timeout as the build exceeded 45 mins, we > terminate the builds after this period as they may be in a hung state. > - #123 & 124; these are really quite a strange ones! There were many > unresolved dependencies (namely aduna and openrdf dependencies), so I can > only assume that the remote repository hosting these dependencies was not > available or off-line for this particular build? > - #125 & 126; we now witness Simo's commit @#125 & Michele's @#126 to > address adding of custom settings file to include Aduna Software external > repo and Improved integration test: renamed test to verify Extractor > plugins detection. Added test to verify CLI plugins detection. Added > minimal Javadoc. This commit is related to issue > #ANY23-54<https://issues.apache.org/jira/browse/ANY23-54>respectively. > As of #125 this changes the nature of the failed build to > comment that > > message : Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy > (default-deploy) on project any23-parent: Failed to deploy artifacts: > Could not transfer > artifact org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28 > from/to apache.snapshots.https > (https://repository.apache.org/content/repositories/snapshots): > > Failed to transfer file: > https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom. > Return code is: 401 > cause : Failed to deploy artifacts: Could not transfer artifact > org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28 > from/to apache.snapshots.https > (https://repository.apache.org/content/repositories/snapshots): Failed > to transfer file: > > https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom. > > Return code is: 401 > > So basically the latest bad output we get begins as of #125 with return > codes of 401. I've taken a look at the build configuration for Any23-trunk > builds and apart from the additional settings for Build | Goals and options > | --settings settings.xml clean deploy, there is nothing out of the > ordinary. > > What is certain though is that we need to have a stable build before we can > get an RC done for the 0.7.0-incubating release! > > I'm tempted to open a Jira as a blocker, then get involved with either some > Jenkins admin's, builds@ or something similar? > > Lewis > > > -- > *Lewis*
