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 <[email protected]> wrote: > On Tue, Jan 19, 2016 at 11:48 AM, Stack <[email protected]> wrote: > > > On Tue, Jan 19, 2016 at 5:46 AM, Sean Busbey <[email protected]> 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. >
