Jenkins ver. 2.73.3
I have a sample build task that is triggered by a commit to a Github repository. This is how the build information looks:
We need to write this username to a separate file and store it in a particular location. How can I achieve it?
**********Edit-1**********
Added a build step that executes a shell command to write the variable GIT_COMMITTER_NAME to a file. This fails(empty file) but if I write, say JENKINS_URL, it is written to the file:
I guess the github plugin doesn't set, by default, the variables like GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL etc.
Taking a cue from this answer, I proceeded with using the placeholders of the 'pretty option' of git show command. I added the following command in the 'Execute Shell' build step of Jenkins job:
git show -s --pretty='GIT_AUTHOR_NAME='%aN%n'GIT_AUTHOR_EMAIL='%aE%n'GIT_COMMITTER_NAME='%cN%n'GIT_COMMITTER_EMAIL='%cE >> github.properties
The output:
GIT_AUTHOR_NAME=LastName FirstName
GIT_AUTHOR_EMAIL=FirstName.LastName#company.com
GIT_COMMITTER_NAME=GitHub Enterprise
GIT_COMMITTER_EMAIL=noreply#github.company.com
Instead of echo $variable name execute env in shell, it will give you all environment variables at the time of execution and then you can pick the correct variable. (From Gitlab to Jenkins its $gitlabUserName)
Related
I am trying to set up builds on Jenkins. When the build is successful, I push a tag of the build using the Post build Action Git Publisher.
Until Now, these have been done manually, with the tag being given the version number, A.B.C.D (which comes from a text file). Now we are using Jenkins, D comes from the $BUILD_NUMBER Jenkins variable, but A.B.C are stored in a text file within the workspace. Is there a way I can pass A.B.C to the git publisher? or will have to do all of the git commands in a script?
Using Jenkins v1.624. Updating not currently possible (before people suggest this)
Not entirely sure if this will work the Post build Action Git Publisher (as I don't use it), and I can only test this on:
Jenkins ver. 2.32.3
EnvInject+Plugin 1.93.1
Groovy+plugin 1.30
Based on suggestion by 'Joerg S' in this post:
Creating a Jenkins environment variable using Groovy
Add a 'Execute Groovy Script' build step to read in the workspace file (tmpFile) containing A.B.C and convert it to a java based properties file - name:value) :
def custom_tag = new File('tmpfile').text.trim()
File propFile = new File('properties.text')
propFile.write "CUSTOM_TAG:"+custom_tag
Then add a 'Inject Environment Variables' build step to read in the new file, so Properties File Path is properties.text
You should then be able to use the ${CUSTOM_TAG} in your post build git publish as the TAG, as now it's an environment variable.
If this doesn't work check out the groovy code in the link above, it might offer something else.
What's the best (or any!) way to put the output of a command in a Jenkins build name?
I'd like to put the output of the git describe command into the build name of a Jenkins job.
I've installed the build-name-setter plugin with the hopes of setting the build name to something like:
${ENV, var="GIT_DESCRIBE"}
I just don't know how to set $GIT_DESCRIBE before the name is set! I've tried using the EnvInject plugin. The only way to dynamically set the environment variables is to use groovy script. This would work well, except my job is running on a remote slave and the groovy script is (apparently) running only on the master.
If you need the "describe" data (i.e. you can't just use the existing $GIT_BRANCH or $GIT_COMMIT environment variables), you could add an "Execute shell step" with:
echo GIT_DESCRIBE=$(git describe) > git.properties
Then after that, add an EnvInject build step which injects properties from the git.properties file.
I tried following the steps outlined by Christopher Orr but my "Execute shell" script seemed to only run after the build had started. In my case GIT_DESCRIBE was never set/injected in time for the build to use it.
After some time researching I found a solution using the "Evaluated Groovy script" step as part of the Environment Injector Plugin. The Groovy script is evaluated pre-build. The main caveat there though is that the .groovy script is not run in the $WORKSPACE. What I ended up doing was executing a shell script located in my app ($WORKSPACE) from the .groovy script and returning its output as a map with GIT_DESCRIBE.
Evaluated Groovy script
def sout = new StringBuilder()
def serr = new StringBuilder()
def proc = "$WORKSPACE/git-describe.sh".execute()
proc.waitForProcessOutput(sout, serr)
def map = [GIT_DESCRIBE: sout.toString()]
return map
git-describe.sh
#! /bin/bash
# change working directory to the current script's directory
cd "${0%/*}"
echo `git describe`
From there you should be able to reference GIT_DESCRIBE in your "Build name" macro.
${ENV, var="GIT_DESCRIBE"}
With build-name-setter plugin v1.6.7 one could do the following:
"Execute shell" build step, which does git describe >version.txt
"Update build name" build step, which takes build name from version.txt.
My question is there any way to set up environment variables from a file during Jenkins build. I have a file called .xyz which has env variables.
I know there is a jenkins plugin but can we do it inside the execute shell box in jenkins??
I tried . .xyz but that doesn't work!
Thanks in advance
If you want to do it from inside Execute Shell step, you've got to write a shell script that will read the file line by line and add them to environment variables.
Assuming your properties file is of format:
var=value
A very basic version of the script would be:
while read line; do
export $line
done <your_props_file_name
The problem is, these variables will only be retained for the duration of that "Execute Shell" build step. Once you move to a different Build step or Post-build step (within the same job), they will be gone. This is Jenkins's cleanup by design.
That's why there is that EnvInject plugin, it takes care of maintaining the environment variables between the build steps.
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.
I have a bash script that looks like this:
#!/bin/sh
previousRelease=`git describe --tags --match "release*" origin/release`
git diff --name-status $previousRelease..origin/release
Is there a way of having Jenkins execute it as part of a build process? The intention is to see a list of files that have changed since the last release, as a manual step to confirm that the release should go up. The user who has triggered the build needs to read the output and then confirm the release should go ahead.
Most things are possible to do in Jenkins but if it is the best way of doing it is another question.
To solve this I would use an approach with two jobs one for checking the diff (hock that one on to the git repository) The other job for doing the actual release.
The check diff job
1 Create a job of the type freestyle project with build type "execute shell" and run your script above. Add some prints at the end of the log to create a clickable link to manually start the release job with current git-id as argument.
Just printing an URL in console output will make it clickable so:
export GITID=`git log -n| grep and sed or awk something`
echo http://jenkins.example.com:8888/job/releaseme/buildWithParameters?label=$GITID¶meters=build
will create the accept changes user interface you requested.
The release job
2 Create another job(above I assumed you named it releaseme) let the job have one parameter as argument (tick "This build is parameterized") make let the argument be the git-id you would like to release. Create your release script in this job.