I'm working on a multi module maven project with Jenkins. I have a Build-Job which I want to package my project with a unique version number and deploy it to Nexus.
The version number should be - where the "maven-version" is the version maintained in the root POM and "build-number" is Jenkins' job build number. For example: 1.2.3-1234
I'm using the maven-versions-plugin to set the desired version number but I have the problem that I want to have the first part of the version (1.2.3) maintained in the POM. So I need a way to extrakt the version from the POM into a Jenkins environment variable.
Until yet I found no direct way of doing this. My solution is to use a groovy script which pares the POM and writes the version number into a temporary property file. After that I use the EnvInject plugin to create the environment varaible for later reinjecting as version number for the "mvn versions:set" command.
My groovy script:
import jenkins.util.*;
def project = new XmlSlurper().parse(new File("pom.xml"))
def version = project.version.toString();
def mainversion = version.substring(0, version.indexOf("-SNAPSHOT"));
println "Version: $mainversion";
def versionFile = new File("v.properties");
versionFile << "VERSION=$mainversion";
This indirection through the property file is very ugly and error prone. Is there any way to directly create an environment variable within the groovy script? It is possible using a system groovy script but these kind of scripts are always executed on the master. So my job will not be runable on slaves which doesn't work for me because I do not execute builds on the master.
Welcome to another version of the Jenkins Chain upstream-downstream variable problem. I assume you are probably trying to do some sort of continuous integration pipeline.
At my company, we solved this one of two ways:
Option 1: Brute force by doing a sed search and replace as a execute shell in the beginning:
#sed -i '0,/<version>.*<\/version>/s/<version>.*<\/version>/<version>'${SVN_REVISION}'<\/version>/g' pom.xml;
#sed -i '0,/<name>.*<\/name>/s/<name>.*<\/name>/<name>'"${JOB_NAME}"'<\/name>/g' pom.xml;
#find . -name pom.xml | xargs sed -i 's/${build.number}/'${SVN_REVISION}'/g';
Option 2: Use Artifactory instead of Nexus and pay for Artifactory Pro. The Build/Release Management functions of the Artifactory jenkins plugin have saved us hours and hours of this kind of grief.
Related
I’m new to Jenkins and currently working on a maven project.
I am able to run a simple Jenkins job using maven commands.
mvn clean install
However, the extended requirement requires me to us an additional parameter in the maven command
mvn clean install -DfileName=file1
Is it possible to have a drop down with file names (e.g. file1, file2 ..) and have the user selected one append to the maven command.
mvn clean install -DfileName = {selected filename from dropdown}.
Could some one please assist with this along with what plugin and how can I setup.
Parameterize your jenkins job see https://wiki.jenkins.io/plugins/servlet/mobile?contentId=34930782#content/view/34930782.
Use choice parameter to add your file name choices
Active Choices Plugin - https://wiki.jenkins.io/display/JENKINS/Active+Choices+Plugin
The user selected choice can be used in your maven command using "{params.param_name}".
This is my build.gradle:
group 'whatever'
version '1.0.0-SNAPSHOT'
...
dependencies {
compile 'whatever:2.2.1-SNAPSHOT'
}
I want to automate releasing process, which includes the need to set both versions to particular values, e.g. 1.1.0 or 2.2.0 using command line only. Any kind of autoincrement is not an option.
With Maven, I'd do this using maven-versions-plugin:
mvn versions:set -DnewVersion=${WHATEVER_NEW_VERSION}
How can I do the same with Gradle? I only found this unanswered question. There must be some simple way to do that?
I ended up extracting version numbers to gradle.properties and updating them as part of the automated build script using sed:
sed -i -e \"/someVersionNumber=/ s/=.*/=${SOME_NEW_VERSION_NUMBER}/\" gradle.properties
It's what I want. Although for me, coming from the Maven background, this doesn't seem natural. I may research another alternative later.
Though not related to publishing, one way to pass command-line properties is as follows:
gradle -PWHATEVER_NEW_VERSION=2.0.0
Consider the following build.gradle snippet:
def newVersion = project."WHATEVER_NEW_VERSION"
println newVersion
See ~/utils/gradle/version.gradle in this project for another approach. It uses separate environment variables for major, minor, and incremental versions and then builds the string automatically. Because it resides in the gradle directory, it can simply be imported into build.gradle, which hides some boilerplate.
I successfully used Axion Release Plugin a couple of times and was very satisfied. Functionality-wise it comes the closest to what Maven's
I'm investigating a Maven/Jenkins/Artifactory set up as a possible solution for a CI/Release process.
I have a job in Jenkins - call it MYJOB - that builds and deploys an artifact to Artifactory. Now, I want another job that I can run manually that will copy the artifact of a particular build of MYJOB from Artifactory and put it somewhere (not too bothered where right now, but eventually it'll be another server).
For example, let's say build #123 went green, and now my QA team want to deploy the built artifact to their environment for further testing (the idea being to keep this artifact intact and unchanged throughout the testing process, before marking it as releasable). I want them to be able to enter '123' into Jenkins as a job parameter and then kick off the build.
So, I figure I need a free-style job that uses a script to do this.
My question is: How can I pass the number of a previous MYJOB build to the job, so that it will get the correct artifact from artifactory?
Alternative methods of achieving my goal are welcomed :)
So I got it working. I put the following code in the Build Step section of a Jenkins Freestyle Build Configuration after defining a parameter called 'REQ_BUILD_NUMBER':
SOMETHING=$(curl "http://MYARTIFACTORYLOCATION/artifactory/api/search/prop?build.number=$REQ_BUILD_NUMBER" | jq --raw-output '.results[0].uri')
echo $SOMETHING
SOMETHING_ELSE=$(curl $SOMETHING | jq --raw-output '.downloadUri')
echo $SOMETHING_ELSE
wget -N --directory-prefix=/var/lib/jenkins/artifacts/ $SOMETHING_ELSE
(NB: I'm barely competent at shell scripting. I'm sure it can be done in a better way)
EDIT: This requires installing 'jq' for the command line.
Create a Parameterized build for the second job. The QA team can put the build number when they start the build. This build number will be available as an environment variable which can be accessed in the scripts which can then retrieve the packages from the repository.
I would like to use Maven to produce an artifact in zip format. To give you some background; my project includes an APS package (Application Packaging Standard, used to provision cloud applications on the Parallels platform). This package is a zip file that contains a combination of XML as well as PHP files. It is generated by an APS plugin from within Eclipse and its name always includes the version and release number of its contents.
What I am trying to do is generate a zip file with Maven that would be kind of a release candidate that will be eventually sent to customers and would include not only the actual APS package but also other files such as README, User Guide.pdf, etc;. I would like the name of this zip file to contain the version number of the version number of the APS package. Currently I can generate this manually by using something like "mvn -Dversion=1.2.3-4 package" but I would like to automate the process and ideally run this from Jenkins.
Basically, my strategy is to run a script that would extract the version number from the initial APS package, once that is done, my script can invoke Maven and can pass this parameter to it so it can generate the final zip with the proper version number. This is fine but again, I need to run this script manually and I am looking for an automated process.
My question is; is it possible to invoke this script from within Maven and use its return as a parameter to set the version name (or the name of the file that will be generated) at run time? As I mentioned, I would like eventually Jenkins to handle this. It can pick up the pom file but I am not sure how it could kind of "auto configure" itself to have the proper version number.
Thanks is advance.
From jenkins build you can use profile with ${BUILD_NUMBER}:
<profile>
<id>jenkins</id>
<build>
<finalName>${artifactId}-${version}-${BUILD_NUMBER}</finalName>
</build>
</profile>
Then run in jenkins:
clean install -Pjenkins
I use the SVN (or any source versioning system) version to identify the software builds.
By simply executing this
REVISION=`svn info | grep '^Revision:' | sed -e 's/^Revision: //'`
on the sourcers folder you get the right value in $REVISION, then you can use it for your maven build
mvn -Dversion=1.2.3-$REVISION package
easy and clean
I have a Maven job in Jenkins. Before the actual build step I have an "Execute shell" pre-build step. In that shell I set a variable:
REVISION=$(cat .build_revision)
I would like to use that variable in the Maven build job in "Goals and options":
clean install -Drevision=${REVISION}
But that does not work! The "Drevision" is set to "${REVISION}" not the actual value of ${REVISION}. Output:
Executing Maven: -B -f /home/gerrit/.jenkins/jobs/<job_name>/workspace/pom.xml clean install -Drevision=${REVISION}
It works with Jenkins environment variables:
clean install -Dbuild=${BUILD_NUMBER}
It sets "Dbuild" to the actual build number. Output:
Executing Maven: -B -f /home/gerrit/.jenkins/jobs/<job_name>/workspace/pom.xml clean install -Dbuild=54
My question: How to use a shell variable in Maven "Goals and options"??
EDIT:
I tried using Jenkins EnvInject Plugin to "Inject environment variables" after the pre-build shell, and my variable is now accessible by e.g. post-build shells, but it is still not available in Maven "Goals and options".
Then it is possible to set "Inject environment variables to the build process" using the EnvInject Plugin, which actually makes those variables available in Maven "Goals and options", but those are set right after SCM checkout, i.e. before pre-build steps, and do not support expression evaluations.
You're on the right track here, but missed a third feature of the EnvInject-Plugin: The "Inject environment variables" build step that can inject variables into following build steps based on the result of a script or properties.
We're using the EnvInject plugin just like that; A script sets up a resource and communicates its parameters using properties that are then propagated by the plugin as environment variables.
i.e. setting up a temporary database for the build:
I had a very similar problem, trying to compute a build version and inject it into the build. After running into all the same issues (not expanding, etc), I used the "Generate environment variables from script" option, which interprets the output as tag=value pairs into Jenkins variables. The script :
#generate a version code that is high enough to surpass previously published clients
val=`expr 150000 + $BUILD_NUMBER`
echo VERSION_CODE=$val
After this, I was able to inject $VERSION_CODE into maven as follows :
-Dbuild.vercode=${VERSION_CODE}
Hope that works for you.
This issue is caused by a bug in the Jenkins Maven Project Plugin as detailed in this bug report opened on 2012-06-22. The plugin has not yet been fixed as of version 2.1.
A fix has been proposed for the Maven Project Plugin, but has not yet been integrated. Here is the link to the pull request: https://github.com/jenkinsci/maven-plugin/pull/14
If you build the plugin yourself with the pull request patch applied, the variables are injected and made available to the "goals and options" field as expected.
I see there is an accepted answer, but for a newbie in Jenkins I found it hard to grasp it all. That's why I would add a bit more detail in this answer and show how I did it.
As #jjungnickel suggested you need to have EnvInject Plugin installed for Jenkins. Then in the Build section > Add build step you'll get option "Inject environment variables".
Basically the idea is:
Add variables you want to access later to a file (might be added by a shell script or it could be file from the file system).
Inject the file with the variables.
Use the variables.
Here a sample setup:
Since I want to use them in maven goal I need to check the Inject Build Variables checkbox.
Then at the end of the build I remove the file just because I want to keep the environment as it was before the build.
I think your best shot is to try the EnvInject plugin for this along with your initial pre-scm step.
You run the pre-scm as you already do.
You use the env inject to load the file for the main job's build steps
Consider loading your file's content (properties format) or execute a script which will load the file as you want and make a variable available for the rest of the job with the "Prepare an environment for the run" option.
I hope this helps.
I needed to resolve the variables before the injection was done so I put this in script content:
Example: (note it doesn't seem possible to simply export variables here so I wrote to files and the help section in jenkins seems to indicate this is expected)
git ls-tree --name-only -r ${sha1} | grep -v -c "*\.md" > diff.bak
git diff origin/master --shortstat | grep "1 files changed" && echo 1 > count.bak || echo 0 > count.bak
I then added this in the groovy script, using the output files I can create a map:
def procDiff = "cat $WORKSPACE/diff.bak".execute()
def procCount = "cat $WORKSPACE/count.bak".execute()
def diff = procDiff.text
def count = procCount.text
print "string val = $diff and count = $count "
if ("0".equals(diff) || !"1".equals(count)){
def map = ["GOAL": "clean verify"]
return map
} else {
def map = ["GOAL": "clean"]
return map
}
Then I could reference $GOAL in my maven build to conditionally trigger a "clean" or a "clean verify" based on the type of PR raised.