0

I have a script called test.sh on a remote server. It prints an environment variable that has been set in the .profile and looks like this:

#!/bin/ksh
echo "JAVA_HOME: $JAVA_HOME"

When I run the script manually I get the same result as with an echo command.

my_user@remote_server$ echo "JAVA_HOME: $JAVA_HOME"
JAVA_HOME: /path/to/java_jdk
my_user@remote_server$ ./test/test.sh
JAVA_HOME: /path/to/java_jdk

The commands I have configured in the Jenkins SSH plugin are the exact same as I executed manually:

echo "JAVA_HOME: "$JAVA_HOME
./test/test.sh

But when I run it I get following output in Jenkins:

JAVA_HOME: /data/work/java/jdk1.7.0_45
JAVA_HOME:

Why can't the environment variables be accessed from within the script?

My .profile looks like this

#!/bin/ksh
# ...
export JAVA_HOME=/path/to/java_jdk
# ...
jschuebel
  • 312
  • 2
  • 15
  • 4
    Try `export`ing `JAVA_HOME` before calling your script. – Paul Hodges Apr 26 '19 at 15:24
  • Have you modified your user *.profile* file or Jenkins user *.profile* file? Can you attach to the question the content of that *.profile* file (at least, the part including JAVA_HOME)? – Jose Camacho Apr 30 '19 at 14:49
  • @PaulHodges Thank you, but when I use `export`, the content of the variable will be set to the value it has on the server jenkins is running on. – jschuebel Apr 30 '19 at 14:55
  • Well...yeah. The variable will be whatever's set on that machine for that environment. You're saying the plugin isn't injecting the value correctly? – Paul Hodges Apr 30 '19 at 15:03
  • I found out it works when I do `ssh usr@remote_srv "bash --login" <<<"./script_i_want_to_run.sh"` from the server jenkins is running on instead of using the _SSH plugin_. – jschuebel Apr 30 '19 at 15:06
  • @PaulHodges I suspect the plugin to not correctly load my profile. Maybe because it is not an interactive session. See my comment above for the workaround I currently use. – jschuebel Apr 30 '19 at 15:10
  • @JoSSI please check my edit. – jschuebel Apr 30 '19 at 15:14
  • Notice that in the workaround you specifically call **bash** shell and in the test script you are using **ksh** shell. I had a similar issue, I solved it by not executing directly the script but specifying the bash; in your case it would be *bash ./test/test.sh* – Jose Camacho May 02 '19 at 09:10

0 Answers0