0

I'm currently struggling with running a .sh script I'm trying to trigger from Jenkins.

Within the Jenkins "execute shell" section, I'm connecting to a remote server (The Jenkins agent does not have right OS to build what I need.), using:

cp -r . /to/shared/drive/to/have/access/on/remote
ssh -t -t username@servername << EOF
    cd /to/shared/drive/to/have/access/on/remote
    source build.sh dev
    exit
EOF

Inside build.sh, I'm exporting R_LIBS to build a package for different R versions.

...
for path in "${!rVersionPaths[@]}"; do
    export R_LIBS="${path}"
    Rscript -e 'install.packages(c("someDependency", "someOtherDependency"), repos="http://cran.r-project.org");'
...

Setting R_LIBS should functions here like setting lib within install.packages(...). For some reason the R_LIBS export doesn't get picked up. Also setting other env variables like http_proxy are ignored. This causes any requests outside the network to fail.

Is there any particular way of achieving this?

tschaka1904
  • 1,303
  • 2
  • 17
  • 39
  • 1
    Is this a bash question? If yes, remove irrelevant details and provide a [mcve]. Otherwise remove the bash tag – oguz ismail Apr 08 '20 at 11:57
  • what is the first line of your shell script? Are using the same shell as the default shell? Though it should not really make a difference. Also will suggest that you put `env` in your shell script to confirm – Tarun Lalwani Apr 13 '20 at 11:53
  • @TarunLalwani The first line is #!/bin/bash – tschaka1904 Apr 13 '20 at 14:17
  • When printing the paths, I do get the right paths back. Also when setting lib within the install packages, it seems to work. But yeah, setting an env variable from the script doesn’t seem to be workings – tschaka1904 Apr 13 '20 at 14:19
  • Also, when manually triggering the script (not using Jenkins) everything seems to run just fine. Soo... do I lose any rights when running a script from a romper Server via SSH? – tschaka1904 Apr 13 '20 at 14:21
  • I have tested through a simple script and it works for me, so I don't think approach is wrong, may be something else is wrong. I would suggest you look at the `env` in ssh before executing the command and also `env` in your bash when you executing it normally – Tarun Lalwani Apr 13 '20 at 14:31

5 Answers5

1

Maybe pass those variables with env, like

env R_LIBS="${path}" Rscript -e 'install.packages(c("someDependency", .....
robert.baboi
  • 354
  • 1
  • 5
0

Well i'm not able to comment on the question, so posting it as answer.

I had similar problem when calling remote shell script from Jenkins, the problem was somehow bash_profile variables were not loaded when called the script from Jenkins but locally it worked. Loading the bash profile in ssh connection solved it for me.

Add source to bash_profile in build.sh

. ~/.bash_profile OR source ~/.bash_profile

Or Reload bash_profile in ssh connection

`ssh -t -t username@servername << EOF
   . ~/.bash_profile
   your commands here
   exit
EOF
akhlaq
  • 19
  • 6
  • It would be better to pull the settings you care about out of your `.bash_profle` file; these files are intentionally not being sourced and you're over-complicating your setup by sourcing them manually. – dimo414 Apr 19 '20 at 21:10
0

You can set that variable in the same command line like this:

R_LIBS="${path}" Rscript -e \
    'install.packages(c("someDependency", "someOtherDependency"), repos="http://cran.r-project.org");'

It's possible to append more variables in this way. Note that this will set those environment variables only for the command being called after them (and its children processes as well).

Luis Lavaire.
  • 599
  • 5
  • 17
0

You said that "R_LIBS export doesn't get picked up". Question Is the value UNSET? Or is it set to some other value & you are trying to override it?

It is possible that SSH may be invoking "/bin/sh -c". Based on the second answer to: Why does 'cd' command not work via SSH?, you can simplify the SSH command and explicitly invoke the build.sh script in Bash:

cp -r . /to/shared/drive/to/have/access/on/remote
ssh -t -t username@servername "cd /to/shared/drive/to/have/access/on/remote && bash -f build.sh dev"

This makes the SSH invocation more similar to invoking the command within a remote interactive shell. (You can avoid sourcing scripts and exporting variables.)

You don't need to export R_LIBSor env R_LIBS when it is possible to prefix any command with local environment variable overrides (agrees with Luis' answer):

...
for path in "${!rVersionPaths[@]}"; do
    R_LIBS="${path}" Rscript -e 'install.packages(c("someDependency", "someOtherDependency"), repos="http://cran.r-project.org");'
...

The Rscript may be doing a lot with env vars. You can verify that you are setting the R_LIBS env var by replacing Rscript with the env command and observe the output:

...
for path in "${!rVersionPaths[@]}"; do
    R_LIBS="${path}" env
...

According to this manual "Initialization at Start of an R Session", Rscript looks in several places to load "site and user files":

  • $R_PROFILE
  • $R_HOME/etc/Renviron
  • $R_HOME/etc/Renviron.site
  • $R_ENVIRON_USER
  • $R_PROFILE_USER
  • ./.Rprofile
  • $HOME/.Rprofile
  • ./.RData

The "Examples" section of that manual shows this:

## Not run: 
## Example ~/.Renviron on Unix
R_LIBS=~/R/library
PAGER=/usr/local/bin/less

If you add the --vanilla command-line option to ignore all of these files, then you may get different results and know something in the site/init/environ files is affecting your R_LIBS! I cannot run this system myself. Hopefully we have given you some areas to investigate.

Eric Bolinger
  • 2,722
  • 1
  • 13
  • 22
0

You probably don't want to source build.sh, just invoke it directly (i.e. remove the source command).

By source-ing the file your script is executed in the SSH shell (likely sh) rather than by bash, which it sounds like is what you intended.

dimo414
  • 47,227
  • 18
  • 148
  • 244