hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Testing and CI -- Apache Jenkins Builds (WAS -> Re: Testing)
Date Fri, 22 Jan 2016 19:33:45 GMT
Related to the below, I just changed the trunk matrix build job to exclude
H2 from the build roster (with Sean's help); it seems to be responsible for
this failure type -- *Caused by: java.lang.IndexOutOfBoundsException:
Index: 0, Size: 0* -- in particular. Here is recent example:
https://builds.apache.org/view/H-L/view/HBase/job/HBase-Trunk_matrix/652/jdk=latest1.7,label=Hadoop/console

Lets see if it helps.

While I have your attention, see the nice checkstyle and findbug graph
trajectories here:
https://builds.apache.org/view/H-L/view/HBase/job/HBase-Trunk_matrix/

St.Ack


On Tue, Jan 19, 2016 at 7:02 PM, Sean Busbey <busbey@cloudera.com> wrote:

> On Tue, Jan 19, 2016 at 11:48 AM, Stack <stack@duboce.net> wrote:
>
> > On Tue, Jan 19, 2016 at 5:46 AM, Sean Busbey <busbey@apache.org> wrote:
> >
> > > We could start forcing a clean repository on every build (though this
> > > seems heavy handed).
> > >
> > > IIRC, we ran into this ages ago and it was one particular dependency.
> > > Presuming we can track down what that was, we could add some pre-build
> > > work that verifies a known good copy of that dependency is present.
> > >
> > > For now, I've blacklisted the H2 build host again, since that's the
> > > only host this has been happening on. We added it back last week so
> > > that Jon could test a fix from infra.
> > >
> > >
> > Thanks Sean.
> >
> > Yeah, clean repo each time would be OTT.
> >
> > If you have pointers on how to find the bad dependency, I'll dig.
> >
> > Of course, all builds fine locally.
> >
> > St.Ack
> >
> >
> >
> Relevant bits from our old precommit build (lucky we kept it! ;) )
>
>
> ----
> ...
> # holding place for local repo
> if [ -d "${WORKSPACE}/maven_repo" ]; then
>   echo "removing hbase artifacts from prior runs."
>   rm -rf "${WORKSPACE}/maven_repo/org/apache/hbase"
>   echo "removing javax.inject in case we got a bad dependency"
>   rm -rf "${WORKSPACE}/maven_repo/javax/inject"
> # uncomment to list entire contents of repo
> #  find "${WORKSPACE}/maven_repo"
> else
>   mkdir "${WORKSPACE}/maven_repo"
> fi
>
> ...
>
> if [ "$?" -ne "0" ]; then
>   echo "test patch failed, checking javax.inject dependency"
>   find "${WORKSPACE}/maven_repo/javax/inject"
>   cat
> "${WORKSPACE}/maven_repo/javax/inject/javax.inject/1/javax.inject-1.pom"
>   exit 1
> fi
> ---
>
> So it looks like javax:inject was the culprit before. A first step would be
> to remove it from our local repos before running; that'll require looking
> up how Yetus names the branch-specific maven repos. A better step would be
> to manually install it from a known good location so we can avoid whatever
> nonsense is happening on H2.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message