Is there any way a Jenkins build can be aware of the Maven version number of a project after processing the POM?
I've got some projects where versioning is controlled by Maven, and in a post-build job we'd like to create a Debian package and call some shell scripts. What I need is for the version number that Maven used to be available as a Jenkins environment variable so I can pass it to post-build actions.
To be clear, I'm not needing to know how to get Jenkins to pass a version number to Maven; instead I want Maven to pass a version number to Jenkins!
You can use the ${POM_VERSION} variable, which was introduced with https://issues.jenkins-ci.org/browse/JENKINS-18272
After a lot of digging around (I never realised how poorly-documented Jenkins is!) I found a quite trivial solution.
Install the Groovy plugin
Add a Post Step to your Maven build of type Execute **system** Groovy script
Paste in the following snippet of Groovy:
Script:
import hudson.model.*;
import hudson.util.*;
def thr = Thread.currentThread();
def currentBuild = thr?.executable;
def mavenVer = currentBuild.getParent().getModules().toArray()[0].getVersion();
def newParamAction = new hudson.model.ParametersAction(new hudson.model.StringParameterValue("MAVEN_VERSION", mavenVer));
currentBuild.addAction(newParamAction);
The build environment variable called MAVEN_VERSION will now be available for substitution into other post-build steps in the usual manner (${MAVEN_VERSION}). I'm using it for Git tagging amongst other things.
As other answers already pointed out, if you are using the Maven project type, you have access to the $POM_VERSION variable. But if you are not, you can use this sequence of steps (ugly but reliable). Doing it this way relies on the same version of maven to determine the pom version (while handling complex parent/child pom inheritance where <version> may not even be present for the child).
Maven step with this goal:
org.apache.maven.plugins:maven-help-plugin:2.1.1:evaluate -Dexpression=project.version -l version.log
Shell step: (You may need to adjust the path to version.log depending on your hierarchy)
echo "POM_VERSION=$(grep -v '\[' version.log)" > props.properties
Inject Environment Variables step (Environment Injector Plugin):
Properties File Path: props.properties
Now you can use $POM_VERSION as if this were a Maven project.
What this does: Uses maven to print out the version together with a mess of output, then greps out the mess of output leaving just the version, writes it to a file using properties file format and then injects it into the build environment. The reason this is better than a one-liner like mvn ..... | grep -v '\[' is that using a Maven step does not make assumptions about the installed maven versions and will be handled by the same auto-installation as any other maven steps.
I used Pipeline Utility Steps plugin in a declarative pipeline job to get Maven version. In the example below I use script variable instead of environment variable, because that can be modified and passed between stages.
def TAG_SELECTOR = "UNINTIALIZED"
pipeline {
agent any
stages {
stage('Build') {
steps {
sh "mvn --batch-mode -U deploy"
script {
TAG_SELECTOR = readMavenPom().getVersion()
}
echo("TAG_SELECTOR=${TAG_SELECTOR}")
}
}
}
}
Note: You must approve the getVersion() method after creating the job in Manage jenkins > In-process Script Approval.
See also:
readMavenPom documentation
We used the Groovy Postbuild Plugin.
String regex = '.*\\[INFO\\] Building .+ (.+)';
def matcher = manager.getLogMatcher(regex);
if (matcher == null) {
version = null;
} else {
version = matcher.group(1);
}
Adding this to Jenkins for use later is a bit tricky. Give this a shot, although I remember this causing us some headaches. (Sorry, we did this a long time ago)
def addBuildParameter(String key, String value) {
manager.build.addAction(new hudson.model.ParametersAction(new hudson.model.StringParameterValue(key,value)));
}
Had the same need and solved as suggested with Groovy parsing the pom.
import jenkins.util.*;
import jenkins.model.*;
def thr = Thread.currentThread();
def currentBuild = thr?.executable;
def workspace = currentBuild.getModuleRoot().absolutize().toString();
def project = new XmlSlurper().parse(new File("$workspace/pom.xml"))
def param = new hudson.model.StringParameterValue("project.version", project.version.toString())
currentBuild.addAction(new hudson.model.ParametersAction(param));
Add this script as a post step of type "Execute system Groovy script" (so it's not needed to install Groovy) and paste the code in the "Groovy command".
Execute the Maven Plugin "exec-maven-plugin" in "Execute Shell" as a "Conditional step" worked for me:
mvn -q -Dexec.executable="echo" -Dexec.args='${projects.version}' --non-recursive org.codehaus.mojo:exec-maven-plugin:1.3.1:exec
Integrate in Jenkins:
-> "Add post-build step"
-> "Conditional steps (single or multiple)"
-> "Execute Shell:"
export MY_POM_VERSION=`mvn -q -Dexec.executable="echo"
-Dexec.args='${projects.version}' --non-recursive org.codehaus.mojo:exec-maven-plugin:1.3.1:exec` && [[
"${MY_POM_VERSION}" == "THE_VERSION_TO_BE_MATCHED" ]] && echo
"CONDITION_IS_MET"
-> "Steps to run if condition is met"
-> Add any build step you need
Notes:
THE_VERSION_TO_BE_MATCHED has to exchanged with your version
'&& echo "CONDITION_IS_MET"' is only for debugging purposes. For the same purpose you can add a '&& echo "MY_POM_VERSION=${MY_POM_VERSION}"' after the mvn command in order to understand what's going on.
This approach is more reliable than a "grep" and it could be an alternative if the Jenkins Ruby Plugin is not installed.
You could also do :
MAVEN_VERSION=`grep A -2 -B 2 "<your_project_name>" pom.xml | grep version | cut -d\> -f 2 | cut -d\< -f 1`-commit-"`echo $GIT_COMMIT`"
Explanation: assuming that you have your project name within a line or two above/below version like a normal pom:
<groupId>org.apache.bigtop</groupId>
<artifactId>bigpetstore</artifactId>
<version>1.0-SNAPSHOT</version>
Then you can easily grep for the artifactId, use the "before/after" grep actions to suck in the version with it, and then grep the version out and use the simple unix "cut" command to splice out the content between "version" tags.
I like the Jenkins-groovy integration, but this is alot easier and will work even on a build server which you dont have control over (i.e. because bash is universal).
Solution:
POM_VERSION=$( \
xmlstarlet sel \
-N x='http://maven.apache.org/POM/4.0.0' \
-t \
-v '//x:project/x:version/text()' \
pom.xml \
)
Explanation:
You can do this in a one-liner using a command-line XPath tool, such as those mentioned at "How to execute XPath one-liners from shell?". I chose XMLStarlet, but they all have similar syntax.
When parsing a POM, you have to account for namespaces. The docs here helped me figure this out.
In order to get the text for an element in XPath, you use the text() function as explained at XPath: select text node.
My POM looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.foo.bar</groupId>
<artifactId>foobar</artifactId>
<version>1.0.6-SNAPSHOT</version>
<packaging>jar</packaging>
The downside here is that if the namespace changes, you have to change the command.
Using 'Execute System Groovy Script' as follows:
import jenkins.util.*;
import jenkins.model.*;
def thr = Thread.currentThread();
def currentBuild = thr?.executable;
def projectManager = build.getProject()
def file = projectManager.getWorkspace().child("pom.xml");
def project = new XmlSlurper().parseText(file.readToString())
def param = new hudson.model.StringParameterValue("currentVersion", project.version.toString())
currentBuild.addAction(new hudson.model.ParametersAction(param));
By using Execute System Groovy script you have direct access to the build, from which you can get the project and thus the "child" file in this case pom.xml.
You won't have to create a new file and as you can see it offers very powerful access to every file within the workspace.
Based on #Akom`s answer the pre steps to have POM_VERSION are:
"Inject environment variables" with property
file your_property_file. Note if you select "Inject environment variables to the build process" the file needs to exist in the jenkins workspace.
run in a pre step execute shell the follwing
bash script.
Script
mvn org.apache.maven.plugins:maven-help-plugin:evaluate -Dexpression=project.version -l project_version
# grep for the version pattern rather than not mentioning '\['
echo "POM_VERSION=$(grep -E '^[0-9.]+(-SNAPSHOT)?$' project_version)" > your_property_file
Related
I would like to add a command line parameter to completetly skip some subprojects for performance reasons. My settings.gradle looks like this:
rootProject.name='MyProject'
if (!rootProject.hasProperty('NO_LIBRARY_BUILD')) {
print "=== BUILDING OF LIBRARY PROJECTS. Pass -PNO_LIBRARY_BUILD to gradle to skip building ==="
include('Lib1')
project(':Lib1').projectDir=file('Path/to/Lib1')
include('Lib2')
project(':Lib2').projectDir=file('Path/to/Lib2')
}
else {
print "=== SKIPPING BUILD OF LIBRARY PROJECTS ==="
}
However, this does not work - passing -PNO_LIBRARY_BUILD still enters the "building" part of the if. I assume that these properties are not passed to rootProject, but somewhere else.
How can I access (more so, how can I check for the existence of) the NO_LIBRARY_BUILD command line parameter from the settings gradle?
I found that what worked was using simply
hasProperty('NO_BUILD_LIBRARIES') without specifying the project.
Tested on Gradle 7.1.1. Just using hasProperty does not work. Using settings.hasProperty('abc') works with -Pabc=true.
Reference: https://docs.gradle.org/current/dsl/org.gradle.api.initialization.Settings.html
I have a gradle task that is created at runtime to call another task ("myOtherTask") which is in a separate gradle file. The problem is if that other task doesn't exist an exception will be thrown. Is it possible to check that a task exists in an external gradle file before attempting to call it?
Example:
task mainTaskBlah(dependsOn: ':setupThings')
task setupThings(){
//...
createMyOtherTask(/*...*/)
//...
}
def createMyOtherTask(projName, appGradleDir) {
def taskName = projName + 'blahTest'
task "$taskName"(type: GradleBuild) {
buildFile = appGradleDir + '/build.gradle'
dir = appGradleDir
tasks = ['myOtherTask']
}
mainTaskBlah.dependsOn "$taskName"
}
You can check if the tasks exists. For example if we wanted to simulate this we could make the task creation triggered by a command line property
apply plugin: "groovy"
group = 'com.jbirdvegas.q41227870'
version = '0.1'
repositories {
jcenter()
}
dependencies {
compile localGroovy()
}
// if user supplied our parameter (superman) then add the task
// simulates if the project has or doesn't have the task
if (project.hasProperty('superman')) {
// create task like normal
project.tasks.create('superman', GradleBuild) {
println "SUPERMAN!!!!"
buildFile = project.projectDir.absolutePath + '/build.gradle'
dir = project.projectDir.absolutePath
tasks = ['myOtherTask']
}
}
// check if the task we are interested in exists on the current project
if (project.tasks.findByName('superman')) {
// task superman exists here we do whatever work we need to do
// when the task is present
def supermanTask = project.tasks.findByName('superman')
project.tasks.findByName('classes').dependsOn supermanTask
} else {
// here we do the work needed if the task is missing
println "Superman not yet added"
}
Then we can see both uses cases rather easily
$ ./gradlew -q build -Psuperman
SUPERMAN!!!!
$ ./gradlew -q build
Superman not yet added
This won't help you find if the task is in a specific external file, but if you just want to determine if a task is defined in any of your imported gradle files...
From gradlew help I see there is a tasks task.
Sadly, gradlew tasks doesn't always show all taks. Some of my projects have an integrationTest task while others do not, in which case I can only go as far as build. However, the default tasks command lists integrationTestClasses but not integrationTest.
From gradlew help --task tasks I can see there is a report expanding --all parameter that we can use.
Now, I can see all tasks via gradlew tasks --all, so a simple grep can tell me whether or not the task I want exists. In bash, this might look like:
TASK="integrationTest"
if gradlew tasks --all | grep -qw "^$TASK"
then
gradlew clean integrationTest
else
gradlew clean build
fi
FYI --
Personally, I needed something to tell me in a git pre-commit hook whether the integrationTest task existed or not, so I know whether I can run gradlew integrationTest or if I have to stop at gradlew build. Not finding an answer here, I kept looking, and this is what I came up with to solve my problem. Hopefully, this is of use to others as well.
I made a little "tool" for stuff like that - maybe it comes in handy for some of you...
$ cat if_gradle_task_exists
#!/bin/sh
TASKS=$(./gradlew tasks --all)
BUILD="./gradlew "
for COMMAND in $#; do
echo "$TASKS" | grep -q "$COMMAND" && BUILD="$BUILD $COMMAND"
done
$BUILD
You can append as many tasks as you like and only the existing ones are executed.
I use it in combination with alias as a kind of super api wrapper for tasks I want to be done in different projects (and I don't want to have to care if any of the specific tasks really do exist):
alias ge='~/.config/bin/if_gradle_task_exists eclipse initDb createTestUsers startLdapServerMock startBrokerMock'
That allows me to be as lazy as ge
stumpf#HV000408:/c/devel/workspace/myproject $> ge
to set up the project for eclipse and prepare all needed servers for local development.
The list of tasks produced will need some time to be set-up, so I wouldn't recommend to use it as a full gradlew wrapper though.
Regards
I want to run the SOAPUI project xmls using Gradle script. The GRADLE script should read the project xmls from soapuiInputs.properties file and run automatically all. Please guide me step by step how to create Gradle script to run the SOAPUI projects in Linux server.
Note: We use SOAPUI version 5.1.2.
Probably the simple way is to call the SOAPUI testrunner directly from gradle as Exec task, like you can do from cli.
In gradle you can define the follow tasks (Note that I try it on windows but to do the same on linux as you ask simply you've to change the paths):
// define exec path
class SoapUITask extends Exec {
String soapUIExecutable = 'C:/some_path/SoapUI-5.2.1/bin/testrunner.bat'
String soapUIArgs = ''
public SoapUITask(){
super()
this.setExecutable(soapUIExecutable)
}
public void setSoapUIArgs(String soapUIArgs) {
this.args = "$soapUIArgs".trim().split(" ") as List
}
}
// execute SOAPUI
task executeSOAPUI(type: SoapUITask){
// simply pass the project path as argument,
// note that the extra " are needed
soapUIArgs = '"C:/location/of/project.xml"'
}
To run this task use gradle executeSOAPUI.
This task simply runs a SOAPUI project, however testrunner supports more parameters which you can pass to soapUIArgs string in executeSOAPUI task, take a look here.
Instead of this if you want to deal with more complex testing there is a gradle plugin to launch SOAPUI project, take a look on it here
Hope this helps,
How do you extract a version number from nuspec into TeamCity?
We have a csproj file with this corresponding nuspec node:
1.3.2
In TeamCity I'd like to do a build of this project and create a NuGet package with version 1.3.2.%build.counter%. For example, 1.3.2.322. It is important the version number is coming from a file within source control (the NuSpec) and I don't want to duplicate this as a variable in TeamCity. Is there a way to extract 1.3.2 from the NuSpec file and use it as a TeamCity variable?
This approach works with version 10+ of TeamCity and gets around issues with Select-Xml and namespaces.
$Version = ([xml](Get-Content .\MyProject.nuspec)).package.metadata.version
$BuildCounter = %build.counter%
echo "##teamcity[setParameter name='PackageVersion' value='$Version.$BuildCounter']"
A couple of approaches I can think of spring to mind, both using TeamCity service messages:
Use a PowerShell build step, something like this (apologies my PS isn't great):
$buildcounter = %build.counter%
$node = Select-Xml -XPath "/package/metadata/version" -Path /path/to/nuspec.nuspec
$version = $node.Node.InnerText
Write-Output "##teamcity[buildNumber '$version.$buildcounter']"
Or, similarly, bootstrap a tool like XmlStarlet:
$buildcounter = "1231"
$version = xml sel -T -t -v "/package/metadata/version" Package.nuspec
Write-Output "##teamcity[buildNumber '$version.$buildcounter']"
This step would need to be added before any other step requiring the build number.
i am using maven2 , hudson and sonar
while doing sonar analysis - i would like some way to append the Hudson build# to the maven version of the project
The project version changes every 2 weeks - so take an example in the first 2 weeks :
<version>abc-SNAPSHOT</version>
after two weeks the next version could be something like :
<version>xyz-SNAPSHOT</version>
what I want is to append the build# to the version already present in pom - which is being picked up and passed to sonar
NOTE:
-Dsonar.projectVersion=xyz-SNAPSHOT-${BUILD_NUMBER}
Here - I am hardcoding the version and dynamically passing the build#
what I want is to be able to dynamically pick up the version from maven ( without changing it ) and simply appending the build# dynamically
any ideas of how this can be achieved ?
Thanks,
satish
You can use Groovy script to read the version and put on environment variable:
Getting Maven Version in Jenkins
I used this script on time to parse the version:
def project = new XmlParser().parse("/pom.xml")
def artifactId = project.artifactId.text().trim()
def version = project.version.text().trim()
println "ArtifactId: [" + artifactId + "]"
println "Version: [" + version + "]"
After set "Additional properties" field with:
-Dsonar.projectVersion=${MAVEN_VERSION}-${BUILD_NUMBER}
If Jenkins don't get the variable, try install:
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
You can use this Jenkins feature: https://github.com/jenkinsci/jenkins/pull/933/files
Basically you can access env variables at build, mapped by Jenkins from Maven GAV info
POM_DISPLAYNAME
POM_DISPLAYNAME
POM_VERSION
POM_GROUPID
POM_ARTIFACTID
POM_PACKAGING
POM_RELATIVEPATH
This is not really a Sonar issue. It's Maven project versioning.
Snaphots are designed to be dynamic. You'll discover under the hood that Maven is saving time-stamped versions in your Maven repository (I don't know how these time-stamps could be passed onto Sonar, which perhaps is what you'd like). Snapshot builds are ideal for CI jobs. software that is never used by non-developers.
What's I'd recommend is either stop using snapshots (build a "release" each time), or just accept the fact that there are two kinds of build in Maven. My rule is that if the code is being used by others then it's no longer a snapshot and should be treated as a release. This creates challenges for emerging methodologies like continuous deployment..... If every build goes to production (or production copy) then snapshots become irrelevant.
Building a release everytime is not that bad. First of all naming convention, I'd recommend:
<major>.<minor>.<patch>.<hudson build num>
The Maven's release plugin will automate most of the pain in managing the details of the release (updating the POM, tagging your SCM system). Finally there is also a useful M2_Release plugin that enables you to trigger a release from Hudson GUI.
Thanks To Andre for pointing me to the other link
I did try it but was running into some issues as noted in the comments
Assuming what I have done is just a workaround and there is a better solution ?
( I am using Hudson )
So I defined a new Job in Hudson ( Build a Maven 2/3 project (Legacy) )
Here I defined a "Groovy PostBuild"
Copied the code in the link that Andre pointed me to :
import hudson.model.*;
import hudson.util.*;
def thr = Thread.currentThread();
def currentBuild = thr?.executable;
def mavenVer = currentBuild.getParent().getModules().toArray()[0].getVersion();
def newParamAction = new hudson.model.ParametersAction(new
hudson.model.StringParameterValue("MAVEN_VERSION", mavenVer));
currentBuild.addAction(newParamAction);
I then "Trigger parameterized build on other projects " and mentioned the job in which I wanted the maven version as mentioend in the pom
Defined a parameter - ${MAVEN_VERSION}
I was then able to get the value of this parameter in the "other" job
So first thanks to Andre - he provided me a solution
I am curious to know if this is a good approach
another question I have is ( which maybe I will start a new thread ) is - how does a Hudson "Free style" job differ from a "Maven 2/3 legacy project"
The reason I ask is the same Groovy script failed in a "free style" while it worked in a "Maven legacy"
Thanks,
satish
Had the same need and solved as suggested with Groovy parsing the pom.
import jenkins.util.*;
import jenkins.model.*;
def thr = Thread.currentThread();
def currentBuild = thr?.executable;
def workspace = currentBuild.getModuleRoot().absolutize().toString();
def project = new XmlSlurper().parse(new File("$workspace/pom.xml"))
def param = new hudson.model.StringParameterValue("project.version", project.version.toString())
currentBuild.addAction(new hudson.model.ParametersAction(param));
Add this script as a post step of type "Execute system Groovy script" (so it's not needed to install Groovy) and paste the code in the "Groovy command".