I've been bitten by this in the past as well. Our precommit env is specific
to hadoop. It launches a specific script, and this script overrides the
jenkins property (source ${WORKSPACE}/nightly/hudsonEnv.sh)
We don't own this script. May be we should just copy its content into the
jenkins shell parameter, but don't remember if there is an impact.
HBASE-8731 was about changing the script itself.On Thu, Dec 26, 2013 at 6:14 AM, Andrew Purtell <[email protected]> wrote: > Ok, so I spoke too soon, the ASF Jenkins builds for 0.98 are both set up to > use "1.6 (latest)", but I had a test here that would fail on one build but > not another, locally on 1.6u43, and on some ASF Jenkins builds but not > others, and never on a 1.7 build (locally). Or a precommit build, which was > 1.6u20. I thought JRE version was the variable but there is something else > uncontrolled here. That's actually worse. So scratch my above suggestions. > I am just going to cut my losses and move on. > > I will not update the ASF Jenkins job configurations until when/if there is > further discussion. > > > On Wed, Dec 25, 2013 at 9:02 PM, Andrew Purtell <[email protected]> > wrote: > > > I should also mention the precommit builds all passed, which suggests to > > me they are using JDK 7 also. > > > > > > On Wed, Dec 25, 2013 at 9:00 PM, Andrew Purtell <[email protected] > >wrote: > > > >> HBASE-6104 introduced a feature developed and tested with JDK 7. > >> Subsequent to review and commit, two builds on ASF Jenkins began > failing, > >> the 0.98 on Hadoop 1.1 build, and the trunk build. After chasing a red > >> herring that looked like a test only failure for a bit it seems the > problem > >> was deeper and manifested on JDK 6. I have reverted the change, > unscheduled > >> the feature from 0.98, and may return to it some time in the future > after > >> the sting wears off. In the meantime, I have two suggestions: > >> > >> 1. We should set all of the primary builds like trunk and 0.98 on Hadoop > >> 1.1 to use JDK 7, like the other builds. The inconsistent use of JDK/JRE > >> version will be an occasional source of confusion. > >> > >> 2. We should explicitly set up jobs that use JDK/JRE 6 and name them as > >> such. > >> > >> -- > >> Best regards, > >> > >> - Andy > >> > >> Problems worthy of attack prove their worth by hitting back. - Piet Hein > >> (via Tom White) > >> > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
