Can Jenkins source .bashrc of associated user? - jenkins

My Jenkins runs inside Tomcat which runs under user buildman, therefore all the jobs run under that user (in CentOS). Some of my jobs depend on environment variables, which I set in .bashrc. However, the Jenkins jobs do not see any of the variables set in that file even though that script is supposed to be sourced for non-login shells, such as what I would think Jenkins should be (?).
The workaround is simple: I just copy and paste all the variables from my .bashrc into the build command script in Jenkins. But that is not very elegant. Is there any way to get Jenkins to source the .bashrc of the user it runs under so that it gets its usual configuration without having to set it separately in each job?

Jenkins creates a temporary sh-script for each script section (at least when using a "classical" project - for the Pipeline approach I'm not sure). This temporary script is executed with sh. On most Linux systems this is a symlink to bash, this SO-post gives some insights.
Also according to the man-pages of bash invoking bash with sh "tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well."
This means the .bashrc is not interpreted at all. However you can try to source the bashrc for each shell-invocation...

So, I tried a few things and the only solutions that seems to work are:
have a shell script in your repo that uses bash
write a file, chmod it via sh and then run it
In both case, there needs to be an executable file with content like:
#!/usr/bin/env bash
...
Using sh """ bash -c "...." """" doesn't seem to work

When my Jenkins agent launches by SSH on redhat linux, I see it does print environment variables defined in .bashrc.
My problem with not seeing changes to .bashrc was because I needed to relaunch the agent, so it picked up the change.

I have found a command that works for me
In .profile, .bashrc, etc.:
export MY_BASH_VAR=123
In Execute Shell:
VAR=$(bash -c "source ~/.profile && echo \$MY_BASH_VAR")
echo $VAR
Will print 123 in the output console when the job builds

Related

How to transform a 'bat' directive from Jenkinsfile for execution in the Script Console?

A 'bat' script from my Jenkinsfile is failing for no apparent reason. I already tested it by physically running it on the agent machine, so now I want to run it under Jenkins manually - through the Script Console. How do I go about transforming this line into the exactly equivalent console command?
bat 'set \"ANDROID_HOME=%USERPROFILE%\\AppData\\Local\\Android\\Sdk\" && gradlew.bat assembleDebug'
I tried this, no luck, I probably didn't escape something correctly, perhaps too many inner quotes for the cmd /c command?
println "cmd \\c \"set \"ANDROID_HOME=%USERPROFILE%\\AppData\\Local\\Android\\Sdk\" && gradlew.bat assembleDebug\" ".execute().text
cmd \c should be cmd /c, and you can also return the command's output like so:
"cmd /c \"set \"ANDROID_HOME=%USERPROFILE%\\AppData\\Local\\Android\\Sdk\" && gradlew.bat assembleDebug\"".execute().text
Anyway, the script console is only the first step to determining run-time issues in pipeline steps, as you only get to know whether the command itself works.
Next you want to isolate your problem in a separate pipeline, so you can work out CPS and sand-boxing problems. Fun stuff.

jenkins shell build step with variable containing a single quote

I'm trying to use jenkins to schedule a repeated job to rsync from a remote directory. Unfortunately I only have ssh password access (no key) so I'm using sshpass to authenticate. The password contains a single quote, and no matter what I do, jenkins always puts a backslash in front of the single quote.
Details:
jenkins is running on centos, installed via yum
build step is a shell
command in shell is basically `sshpass -p my'pass rsync -avc me#remotehost.com: /my/dest/dir/
variations I've tried:
put the password in a file then use sshpass -f
reports authentication fails
put the above command in a script file, have the jenkins build run that script
use jenkins credentials / associated variables
all variations of double quoting / string concatenation
Note that all of the things I've tried work fine on the command line and/or via crontab (I'm trying to use jenkins instead of crontab though...)
Any ideas?
Try to use Groovy multiline string literal for the shell block:
stage{
sh """
sshpass -p my'pass rsync -avc me#remotehost.com: /my/dest/dir/
"""
}

In Jenkins, on a Windows remote connected through Cygwin sshd, how to run an sh pipeline step?

We are porting our Jenkins pipeline to work on Windows environments.
The Jenkins' master connects to our Windows remote -named winremote- using Cygwin sshd.
As described on this page, the Remote root directory of the node is given as a plain Windows path (in this case, it is set to C:\cygwin64\home\jenkins\jenkins-slave-dir)
This minimal pipeline example:
node("winremote")
{
echo "Entering Windows remote"
sh "ls -l"
}
fails with the error:
[Pipeline] echo
Entering Windows rmeote
[Pipeline] sh
[C:\cygwin64\home\jenkins\jenkins-slave-dir\workspace\proto-platforms] Running shell script
sh: C:\cygwin64\home\jenkins\jenkins-slave-dir\workspace\proto-platforms#tmp\durable-a739272f\script.sh: command not found
SSHing into the Windows remote, I was able to see that Jenkins actually created workspace subdirectory in C:\cygwin64\home\jenkins\jenkins-slave-dir, but it is left empty.
Is there a known way to use the sh pipeline step on such a remote ?
A PR from blatinville, that was merged a few hours after this question, solves this first issue.
Sadly, it introduces another problem, described in the ticket JENKINS-41225, with the error:
nohup: failed to run command 'sh': No such file or directory
There is a proposed PR for a quickfix of this issue.
Then there is a last problem with how the durable-task-plugin evaluate if a task is still alive using 'ps', with another PR fixing it.
Temporary solution
Until those (or equivalent) fixes are applied, one could compile a Cygwin compatible durable-task-plugin with the following commands:
git clone https://github.com/Adnn/durable-task-plugin.git -b cygwin_fixes
cd durable-task-plugin/
mvn clean install -DskipTests
Which notably generates target/durable-task.hpi file, which can be used to replace the durable-task.jpi file as installed by Jenkins in its plugins folder. It is then required to restart Jenkins.

Jenkins not able to execute script

I tried to execute a script
./script.sh
from normal terminal window this works.
Same script i call from jenkins execute shell
echo "start"
./script.sh
echo "end"
Then end is never printed it gives a build failure while executing the script itself.
Anything which I may be missing
May I suggest that you cd to the workspace directory before calling the shell script shell.sh. Use the cd command with Jenin's workspace environment variable. (After the 'echo start' line.)
If you want to be able to run the same script in Jenkins and outside of Jenkins, then you can delect if the workspace environment variable returns a value, if so cd to it, if not, ignore it.

Can't access build parameters in excute shell in jenkins

I'm trying to call a python script through an execute shell step in a Jenkins parametrized build. The problem is I need to pass the build parameters to the python script which doesn't happen. Here is how I call the python script in execute shell:
python2.7 C:\test\my_script.py -m $module
$module is passed as an empty string.
I've tried in Execute Windows batch command with %module% and it worked fine.
But I need to run it on an excute shell not a windows batch command.
It looks like you are running on Windows ("C:\test\my_script.py ..."), so "Execute shell" will not work properly.
Should either use Execute Windows batch command or move your job to a Unix/Linux machine (can use a Jenkins-Agent for that).
Try this
python2.7 C:\test\my_script.py -m $MODULE
From the documentation
Note that because of the case sensitivity difference of environment
variables in Windows and Unix, all the environment variables added by
parameters are in upper case.
Hence please try using $MODULE instead of $module

Resources