Anyone know how I can set the environment variable value based on unix terminal command in jenkins using inject variable or some other way. e.g CurrentBranch=ls /project/folder | grep my_name. This doesn't seem to work. I want this command,ls /project/folder | grep my_name, to be evaluated and the result should be set to CurrentBranch.
Some reason CurrentBranch variable value never gets evaluated but rather it always has a value as this: ls /project/folder | grep my_name
Anyone knows what I am doing wrong.
Thanks.
I don't think you can do this in a way so that it is available to any Jenkins task, which is written.
You can however write your Jenkins task so that all of them are executing a shell script, and then your question boils down to sourcing a suitable rc file (we use for instance zsh as a shell and have a special rc file just for Jenkins), and inside this file, you can set your environment in the usual way, i.e.
export $(ls /project/folder | grep my_name)
(Of course, grepping the output of ls in this way is not the best idea, but this is a different topic)
You can save CurrentBranch in a file called env and inject that file into your job using EnvFile Plugin
echo "CurrentBranch=`ls /project/folder | grep my_name`" > /tmp/env
In the jenkins job configuration, check the checkbox "Prepare an environment for the run" .
select below checkboxes
Keep Jenkins Environment Variables
Keep Jenkins Build Variables
in the "Script Content" section, run below command to create properties file
echo "CurrentBranch=`ls /project/folder | grep my_name`" > /tmp/jenkins_job.prop
then in "Properties File Path" section, give this properties file with full path name.
now CurrentBranch variable will be avialable through out the build and can be access using ${CurrentBranch} .
Related
I tried so many ways to store a value in jenkins. But I could not assign a value into a variable in Shell script of Jenkins.
First I have set a ENV variable called branch which has the value is */release/hotfix
So I tried to spliit that word and save in new variable like this.
VALUE=$($branch | sed -e 's/\*\/.*\///g')
I tried so many experiment to save the value. It won't work.
In my research, I found a way to assign a value to variable but the plugin ( How to set environment variables in Jenkins? ) may not be safe to use.
why cant i save value to variable in Jenkins shell? How do I do that?
I found the way to achieve this problem.
first I create a file using touch command
touch enviroments.cfg
Then save value into variable while saving to that file
echo "export VALUE=$(echo $branch | sed -e 's/\*\/.*\///g')" >> enviroments.cfg
to access the that saved variable again, I reopened that file and get that value like this
. './enviroments.cfg' (you can not use **source** command to read, use **dot**(.) instead of **source** command)
echo $VALUE
You can read values anywhere like this.
I am trying to put a source command in a bash script so that I can quickly set up and use a virtual environment when writing django websites.
I tried the following without much success as my path was not prefixed with the (path) like it does when I simply enter it at the prompt.
#!/bin/bash
current=$(pwd | cut -d'/' -f5)
source ~/Documents/virtual-env/$current/bin/activate
Can anybody help and let me know what I am overlooking?
EDIT:
pwd is "example" and the source is:
"~/Documents/virtual-env/example/bin/activate".
After some research I think I need to use something like:
"source ./script"
(not working) as I think the environment is created but not esculated to its parent enviroment which I believe is not possible now.
#!/bin/bash
current=$(basename $(pwd))
source ~/Documents/virtual-env/$current/bin/activate
exec bash # Run new interactive shell in the new environment
But I recommend to try virtualenvwarpper instead.
I have a script to manipulate some log files and then push them up to a server, to be loaded into mysql and analyzed. I have almost all of this process figured out except the automation of collecting the logs. I use sed to rip all the " out of the log files, so it can more easily be imported into mysql. When I run the command below it works fine, but run the same command in a shell script, and it creates an empty file. I am not sure why --any help would be greatly appreciated.
sed 's/\"//g' /usr/local/tomcat/logs/localhost_access_log.$yest.txt > /$DIR/iweb$yest.txt
Here is the complete script.
#!/bin/bash
#Script to manage catalina logs on our servers.
#First create the needed variables.
date=$(date +"%m_%d_%y")
adate=$(date +"%Y-%m-%d")
yest=$(date -d 'yesterday' +"%Y-%m-%d")
Customer="iwebsup"
log=/isweb/admin/catmanage/log
DIR=/catmanage
#Make Directory
#mkdir /catmanage/tomcat1/
#Run access logs through sed to remove " from file
echo "Removing quote marks from access log and moving to direcotry" &> $log.$date
sed 's/\"//g' "/usr/local/tomcat/logs/localhost_access_log.$yest.txt" > "/$DIR/iweb$yest.txt" &> $log.$date
Your original question shows redirection with > but your actual script has &>. These are rather different things, and in fact, the latter is probably incompatible with your sh.
The portable, compatible way to include error redirection is
command >file 2>&1
Your shebang line says #!/bin/bash but based on your diagnostic remarks, I am guessing you are running this with sh after all.
By the way, tr -d '"' <file >newfile would be a more efficient way to remove double quotes from a file.
Launching a shell script starts a new system process. I suspect that within the context of this script's sub-shell, $yest is not set as a shell variable. If you're going to use $yest in a shell-script, you should ideally pass its value as an argument to the script -- or alternatively export the shell variable as an environment variable (export $yest) which will be inherited by the sub-shell process (all child processes inherit the environment of their parent process).
When debugging shell scripts, it's always useful to include set -xvu at the start of the section that you're debugging so that you can see what the script is doing and what values are stored in its variables.
-x Print commands and their arguments as they are executed.
-v Print shell input lines as they are read.
-u Treat unset variables as an error when substituting.
You can turn off this debugging by later running set -xvu.
Execution of
user#EWD-MacBook-Pro:~$ export property.name=property.value
Gives me
-bash: export: `property.name=property.value': not a valid identifier
Is it possible to have system properties with dot inside? If so how do that?
As others have said, bash doesn't allow it so you'll have to use your favourite scripting language to do it. For example, in Perl:
perl -e '$ENV{"property.name"} = "property.value"; system "bash"'
This will fire up a subshell bash with the property.name environment variable set, but you still can't access that environment variable from bash (although your program will be able to see it).
Edit: #MarkEdgar commented that the env command will work too:
env 'property.name=property.value' bash # start a subshell, or
env 'property.name=property.value' command arg1 arg2 ... # Run your command
As usual, you only require quotes if you need to protect special characters from the shell or want to include spaces in the property name or value.
I spent better part of this afternoon trying to figure out how to access some property set by Jenkins (to pass a job parameters jenkins uses property format with a dot) - this was a good hint from Adrian and yes it works for reading properties in the script too. I was at a loss as to what to do but then I tried:
var=`perl -e 'print $ENV{"property.name"};print "\n";'`
This worked quite well actually. But of course that works in a shell that was started with the property set in the environment already i.e. in Adrian's example this could work in a script started from bash instance invoked in perl example he provided. It would not if this perl sniplet was put in the same shell only directly after his perl example.
At least I learnt something this afternoon so not all this time is a waste.
If you export those properties to run an application, some programs can support setting system property as an option, and allow . in the property name.
In Java world, most of tools support setting system property by -D option, e.g. you can set system property with dot like this -Dproperty.name=property.value.
Bash only permits '_' and alpha numeric characters in variable names. The '.' isn't permitted.
http://tldp.org/LDP/abs/html/gotchas.html
I'm observing strange unexpected behavior and want your advice,
whether it's a bug in Jenkins/Jenkins plugin,
or I'm missing the point and should use Jenkins differently.
My task:
I got a freestyle project with an optionally set string parameter.
If the user specifies a value for this parameter, build should use this value. If the user didn't specify a value, build should compute a value and use it.
The resulting value should be used in several other build steps,
including shell scripts and triggered builds on other projects.
The shortened list of build steps that I have is:
Execute shell
[ -n "$VERSION" ] && echo "VERSION=$VERSION" > new_env || echo "VERSION=12345" > new_env
Inject environment variables, Properties File Path: new_env
Execute shell
foo "$VERSION"
Trigger/call builds on other project using predefined parameters: upstream_version=$VERSION
Problem:
Now, if the user does not specify a value for VERSION,
shell script at step 3 receives an empty value (WRONG! well, at least unexpected to me)
build on other project called with upstream_version=12345 (correct)
Feels pretty strange - why does the triggered build receive the new value and the shell script doesn't?
Jenkins version is 1.625.3.
What you need is a way to check if variable is defined and not-empty. Bash has built in for it. (-z)
if [ -z "$VAR" ];
More details at question in server fault question: How to determine if a bash variable is empty?