I have branch with this format: release/1.0.0
When I use ${GIT_BRANCH}, I get the following: origin/release/1.0.0
I have tried using EnvInj to set a variable like this:
If I leave ${GIT_BRANCH} the way it is it works fine, but if i use ${GIT_BRANCH, fullName=false}. It is always a empty string.
I have also tried using: How to receive local Git branch name with Jenkins Git plugin?
What is correct format to get just 1.0.0.0-rc134
You can always write a small bash script to get this done.
Use a execute shell build step
echo "RELEASECANDIDATE=${GIT_BRANCH##*/}-rc${BUILD_NUMBER}" > ${WORKSPACE}/inject.txt
Use a Inject shell and in the properties file section give the file name
${WORKSPACE}/inject.txt
Finally in the update build name , use macro below variable
${RELEASECANDIDATE}
This should get you correct value as expected
Use below command at execute bash to get any part of the branch string you want. I am getting the mid part here. Keep in mind it starts counting from left and from 1.
SUBSTR=$(echo $GIT_BRANCH | cut -d'/' -f 2)
I continued the search and found a better solution for this problem at the link below. Basically rather than using $GIT_BRANCH, you can add one additional behaviour after git pull and "check out to specific local branch" and then use $GIT_LOCAL_BRANCH that will return what you expect and is compatible with all plugins (at least with FTP plugin that I used). Please see it in more details at the link below:
How to receive local Git branch name with Jenkins Git plugin?
Try to get ${GIT_LOCAL_BRANCH}. It returns only branch name.
Related
In my TFS release i added a script to create a label when a certain environment succeeds.
This label is apply on a given server item and for a specific Changeset.
The TF.exe command looks like this:
tf.exe label Main-Approved $/MyProject/Main /recursive /version:C124730 /comment:"Approved by Main Release" /collection:http://tfsserver:port/tfs/MyCollection
However when run from the release i get the following error message return by TF.exe:
Error: There is no working folder mapping for D:\Agent-Default_work\r144\a\by.
Running this exact command localy works fine and creates the label.
I don't understand why i would need to create a workspace and some folder mapping in order to apply a label on a Server item (using $/...) for a specific changeset?
Any help would be appreciated.
Thanks!
So i was using a Python script to run the command.
I tried changing it to a powershell script and it works.
My guess is that in python the strings were passed incorrectly someone. I feel like the workspace 'by' was in fact my command wrongly parsed by the intepreter and considered an argument in tf.exe.
I have a local instance of Jenkins. I have previously tried storing the jenkins.yml in my system and giving its path on http://localhost:8080/configuration-as-code. This worked but I want to use a Gitlab repository to store the jenkins.yml file.
I have already tried giving the gitlab link of my jenkins.yml in the path or URL textbox. Some weird things happened, like
1. jenkins broke or huge error console
2. It reapplies the previous configuration(from system path)
jenkins:
systemMessage: "Hello, world"
Your problem as described: you want the job configuration to be saved in GIT and, when a build is triggered, the job should get the current stand of its configuration from there and then, run the build.
Maybe there is a kind of plug-in that does it for you, but I am not aware of any. Maybe anyone?
My suggestion is to define a pipeline job and use a declarative pipeline. It is a file, normally named Jenkinsfile that can be stored in GIT. In the Job, you define the GIT address and when you trigger a build, the file is got from GIT and executed.
There are several flaws in this: pipelines learning curve is not small, you are confronted with groovy (not XML!) and your current XML file is barelly useful.
Maybe someone shows up and tells us about new (for me) plugin that solves your problem using the configuration XML file. In the other hand, pipelines are such a beautyful feature that I encourage you to give it a try
I want to access and grep Jenkins Console Output as a post build step in the same job that creates this output. Redirecting logs with >> log.txt is not a solution since this is not supported by my build steps.
Build:
echo "This is log"
Post build step:
grep "is" path/to/console_output
Where is the specific log file created in filesystem?
#Bruno Lavit has a great answer, but if you want you can just access the log and download it as txt file to your workspace from the job's URL:
${BUILD_URL}/consoleText
Then it's only a matter of downloading this page to your ${Workspace}
You can use "Invoke ANT" and use the GET target
On Linux you can use wget to download it to your workspace
etc.
Good luck!
Edit:
The actual log file on the file system is not on the slave, but kept in the Master machine. You can find it under: $JENKINS_HOME/jobs/$JOB_NAME/builds/lastSuccessfulBuild/log
If you're looking for another build just replace lastSuccessfulBuild with the build you're looking for.
Jenkins stores the console log on master. If you want programmatic access to the log, and you are running on master, you can access the log that Jenkins already has, without copying it to the artifacts or having to GET the http job URL.
From http://javadoc.jenkins.io/archive/jenkins-1.651/hudson/model/Run.html#getLogFile(), this returns the File object for the console output (in the jenkins file system, this is the "log" file in the build output directory).
In my case, we use a chained (child) job to do parsing and analysis on a parent job's build.
When using a groovy script run in Jenkins, you get an object named "build" for the run. We use this to get the http://javadoc.jenkins.io/archive/jenkins-1.651/hudson/model/Build.html for the upstream job, then call this job's .getLogFile().
Added bonus; since it's just a File object, we call .getParent() to get the folder where Jenkins stores build collateral (like test xmls, environment variables, and other things that may not be explicitly exposed through the artifacts) which we can also parse.
Double added bonus; we also use matrix jobs. This sometimes makes inferring the file path on the system a pain. .getLogFile().getParent() takes away all the pain.
You can install this Jenkins Console log plugin to write the log in your workspace as a post build step.
You have to build the plugin yourself and install the plugin manually.
Next, you can add a post build step like that:
With an additional post build step (shell script), you will be able to grep your log.
I hope it helped :)
Log location:
${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_NUMBER}/log
Get log as a text and save to workspace:
cat ${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_NUMBER}/log >> log.txt
For very large output logs it could be difficult to open (network delay, scrolling). This is the solution I'm using to check big log files:
https://${URL}/jenkins/job/${jobName}/${buildNumber}/
in the left column you see: View as plain text. Do a right mouse click on it and choose save links as. Now you can save your big log as .txt file. Open it with notepad++ and you can go through your logs easily without network delays during scrolling.
I found the console output of my job in the browser at the following location:
http://[Jenkins URL]/job/[Job Name]/default/[Build Number]/console
This is designed for use when you have a shell script build step. Use only the first two lines to get the file name.
You can get the console log file (using bash magic) for the current build from a shell script this way and check it for some error string, failing the job if found:
logFilename=${JENKINS_HOME}/${JOB_URL:${#JENKINS_URL}}
logFilename=${logFilename//job\//jobs\/}builds/${BUILD_NUMBER}/log
grep "**Failure**" ${logFilename} ; exitCode=$?
[[ $exitCode -ne 1 ]] && exit 1
You have to build the file name by taking the JOB_URL, stripping off the leading host name part, adding in the path to JENKINS_HOME, replacing "/job/" to "/jobs/" to handle all nested folders, adding the current build number and the file name.
The grep returns 0 if the string is found and 2 if there is a file error. So a 1 means it found the error indication string. That makes the build fail.
Easy solution would be:
curl http://jenkinsUrl/job/<Build_Name>/<Build_Number>/consoleText -OutFile <FilePathToLocalDisk>
or for the last successful build...
curl http://jenkinsUrl/job/<Build_Name>/lastSuccessfulBuild/consoleText -OutFile <FilePathToLocalDisk>
I have my Jenkins job defined to use a timestamp for the build name. I'd also like to be able to use that build name in the code being built. For example, suppose my application prints a "startup" message during initialization. Ideally, I would be able to somehow inject the build name into this startup message.
Example:
Application XYZ, build 20160503-0420, is starting up...
I'm curious what sort of techniques folks have come up with to do something like this.
Thanks!
Well, at first insert build number directly into your code it`s very bad practice.
We create debian package by Jenkins. Debian packages contains control file, some kind of description of package, version, dependency, etc.
In our repo control file contains
Section: misc
Priority: optional
Package: #packagename
Version: 0.1.0+#build~#repo
As you see we keep fixed only major version of software
Then we create package we replace texts started by # with build variables
sed -i 's/#build/$(BUILD_NUMBER)/' $(FAKEROOT)/DEBIAN/control
sed -i 's/#repo/$(REPONAME)/' $(FAKEROOT)/DEBIAN/control
sed -i 's/#packagename/$(PROJECTNAME)/' $(FAKEROOT)/DEBIAN/control
And after that we publish, deploy, send email, doing all Jenkins magic.
I think you can build binary and distribute it
Of course if you want to add this changes into you repository you can use Git publisher, or another source management systems, but tell you again this is bad practice.
We use powershell plugin in Jenkins and this is how we write our job ...
Write-Host Build id $env:BUILD_NUMBER started at Get-Date
For more build parameters refer to below URL
https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-JenkinsSetEnvironmentVariables
What I'd like to do is to be able to add a tag to commits which Jenkins is building from. Right now I tag commits with the Jenkins build number but I want to also add in the app version as listed in the Info.plist CFBundleVersion in front of that.
What I want to know is, how I can grab that value using Jenkins or otherwise and be able to use that as a parameter/variable within Jenkins?
I've seen references to using plistbuddy to set this value so I would assume there's a way to use that to get the same value. Though how and how to get that to where I can use it in Jenkins I don't know.
For further clarification I am using Git Publisher in Jenkins to create a tag and push it with this format
jenkinsbuild-$BUILD_NUMBER
This results in a tag on the commit in git like this - jenkinsbuild-303
What I want, assuming my app is currently at version 3.5 is a tag that reads - jenkinsbuild-3.5-303
I managed to piece together a solution from the answer which #agy linked to. Here's what I did:
In the Build section for the Jenkins configuration, I added the following two lines to an 'Execute Shell' step after the Xcode step:
APP_VERSION=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "path to your plist")
echo APP_VERSION=$APP_VERSION > appversion.properties;
After that, I added an 'Inject Environment Variables' step (I think this is part of the EnvInject plugin), to which I added "appversion.properties" to the Properties File Path field.
After this is done, APP_VERSION is now available as an environment variable in subsequent shell command steps.