expectations for java_home in docker mode

[Sean Busbey <bu...@apache.org>]

I'm seeing some behavior and I don't know if my expectations are wrong
or if something is amiss in how Yetus relaunches under docker.

I've got a project specific Dockerfile that's trying to use jdk7 from
Azul Systems.

In my Dockerfile, I install the jdk and attempt to make sure it's seen
as JAVA_HOME.

e.g. Assuming the needed repository has been set up:

RUN apt-get -q install --no-install-recommends -y zulu-7
RUN update-alternatives --config java
RUN update-alternatives --config javac
ENV JAVA_HOME=/usr/lib/jvm/zulu-7-amd64
ENV PATH="${JAVA_HOME}/bin:${PATH}"

If I use this Dockerfile as my project dockerfile for a yetus
test-patch run, I always get the message that Yetus has overridden the
JAVA_HOME to point at the openjdk JRE (which doesn't work for my
build). Looking at the code, this should only happen if JAVA_HOME
isn't defined.

If instead I generate an image from the Dockerfile and then tell
docker to run an interactive container to give me a shell, I can see
JAVA_HOME and PATH with what I expect. If I install Yetus in the
container via this same shell and run it in non-docker mode it
similarly picks up JAVA_HOME and uses it as I would expect.

Currently I'm working around the issue by passing in --java-home when
test-patch is executed, but I'd prefer to have things work via the
environment variable from the Dockerfile since it would ease
maintenance when I need to change things.

If this isn't clear enough, I believe I can put together a small
reproduction project.

Re: expectations for java_home in docker mode

[Sean Busbey <bu...@apache.org>]

oh interesting. So that means my attempt to ensure there was no java
home before running test-patch would mean we'd set it to the empty
string.

okay that makes a lot more sense than just mysteriously ignoring
Dockerfile environment stuff.

I'll get a patch together with the workaround you suggested.
On Sat, Sep 15, 2018 at 5:14 AM Allen Wittenauer
<aw...@effectivemachines.com.invalid> wrote:
>
>
> > On Sep 14, 2018, at 2:34 PM, Sean Busbey <bu...@apache.org> wrote:
> > ENV JAVA_HOME=/usr/lib/jvm/zulu-7-amd64
>
>         I’m pretty sure this gets overridden because docker.sh does this:
>
>   DOCKER_EXTRAARGS+=("--env=JAVA_HOME=${JAVA_HOME}”)
>
>         Given how many features have been added to Docker since the docker support was added (build args in particular) this whole thing needs a major rewrite.  But until then, a quick fix would be to pass this in as a different var and then make launch-test-patch use that if JAVA_HOME isn’t set. i.e.:
>
>
> —snip---
> cd "${BASEDIR}" || exit 1
>
> JAVA_HOME=${JAVA_HOME:-${PRE_DOCKER_JAVA_HOME}}
>
> if [[ -n ${JAVA_HOME}
>
> —snip—
>
> or whatever
>

Re: expectations for java_home in docker mode

[Allen Wittenauer <aw...@effectivemachines.com.INVALID>]

> On Sep 14, 2018, at 2:34 PM, Sean Busbey <bu...@apache.org> wrote:
> ENV JAVA_HOME=/usr/lib/jvm/zulu-7-amd64

	I’m pretty sure this gets overridden because docker.sh does this:

  DOCKER_EXTRAARGS+=("--env=JAVA_HOME=${JAVA_HOME}”)

	Given how many features have been added to Docker since the docker support was added (build args in particular) this whole thing needs a major rewrite.  But until then, a quick fix would be to pass this in as a different var and then make launch-test-patch use that if JAVA_HOME isn’t set. i.e.:


—snip---
cd "${BASEDIR}" || exit 1

JAVA_HOME=${JAVA_HOME:-${PRE_DOCKER_JAVA_HOME}}

if [[ -n ${JAVA_HOME}

—snip—

or whatever