Thank you Sean (and Andrew) St.Ack On Jan 22, 2016 10:12 PM, "Sean Busbey" <bus...@apache.org> wrote:
> Andrew in infra made us a label that covers all the hosts save H2. > I've updated all the nightly builds to use it. > > (specifying a label expression as we do in precommit doesn't work on > matrix builds because the & and | from the expression end up in the > filesystem path) > > On Fri, Jan 22, 2016 at 3:08 PM, Sean Busbey <bus...@cloudera.com> wrote: > > we should probably ensure the earlier branch builds also exclude H2. > > > > I'll leave myself a note to look at it this evening. If anyone gets to it > > before then, please update here. > > > > On Fri, Jan 22, 2016 at 1:33 PM, Stack <st...@duboce.net> wrote: > > > >> 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 <bus...@cloudera.com> > wrote: > >> > >> > On Tue, Jan 19, 2016 at 11:48 AM, Stack <st...@duboce.net> wrote: > >> > > >> > > On Tue, Jan 19, 2016 at 5:46 AM, Sean Busbey <bus...@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. > >> > > >> > > > > > > > > -- > > Sean >
