Can't access build parameters in excute shell in jenkins - 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

Related

Passing env/params values to the Shell Service plugin of Jenkins

Shell Service of Jenkins plugin is like in the picture that is below. I need to pass params/env variable to it but couldn't make it.
Is there any way to pass values into "Execute shell script on remote host using ssh"?
If this plugin works as a usual ssh command, you can escape $DOCKER_REGISTRY quotes
ssh jenkins#192.168.13.156:22 "echo \"$DOCKER_REGISTRY\""
IMHO: Get rid of the ssh plugins in Jenkins, just use shell, is way more flexible.

How to set a task variable from a remote powershell script?

From a release definition,
When I execute the following powershell script with the powershell task, it works
successfully and I can retrieve the value from the following tasks in the release definition :
Write-Host "##vso[task.setvariable variable=sslThumbprint]toto"
When I execute the exact same script thanks to the "Powershell on target machine task", I don't get any value.
How can I set a variable from a powershell script that do not execute on the agent machine ?
Regards,
This can only be done in case of hosted agents. If you are using hosted agents then only you will be able to run the commands on the agent's machine.
Microsoft as of now provides no feature for doing this.

Can Jenkins source .bashrc of associated user?

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

Use of Jenkins environment variable in directory path

I'm relatively new to the Jenkins world and I'm having issues with the use of environment variables.
I'm currently running builds from code I check out from a git repository. I have an environment variable called GIT_BUILD_NUMBER that I pull from the checkout and use successfully in a Windows Batch Command Block:
::Build Project
python buildProj.py --branch %Branch% --bin_src %WORKSPACE% --build_number %GIT_BUILD_NUMBER%
This executes successfully with the proper git build number. In the very next "Execute Windows Batch command" block, I simply try to use that same variable in a directory path and this causes the build to fail:
J:\builds\%GIT_BUILD_NUMBER%\
I've also tried this:
J:\\builds\\%GIT_BUILD_NUMBER%\\
When I echo this line, I just get:
J:\builds\\
Any insight would be greatly appreciated.

Preserve environment variables in Jenkins between Windows build commands

I am trying to set up Jenkins to continually check out and build code and verify that the code is compilable.
Our build system works like this: we have several different .bat files that set up environment variables for different build configurations, and then we execute gmake to actually build the code.
When I created Jenkins job, in Build part of the job I set up two "Execute windows batch command" commands: one that calls the script to set up env. variables, and gmake to build it.
Problem is, when gmake step runs, all environment variables are forgotten. How can I prevent env. variables from being cleared?
Tx
What if you set it up to call only one bat file instead? That one file can then call the two you're currently calling with Jenkins.

Resources