Jenkins job with different maven versions - maven

I have a maven Jenkins job, that is part of a multijob. Τhis used to run always on windows nodes, but currently we have created some linux nodes, too, that we want to utilize.
The thing is that inside the job,at build step you have to choose:
This maven version applies when building the job. For example the maven version that applied here,, is linked to the path were maven is installed for windows. So this path, is applicable only for windows nodes, therefore, the job cannot be run by a linux node. Is there a workaround for this?
thanks!

You can achieve it using Jenkins pipeline. Just set two maven config in Jenkins > global tool configuration. One for windows maven and other for linux.
node {
def mvnHome
stage('Build') {
// Run the maven build
if (isUnix()) {
mvnHome = tool 'Maven-linux'
sh "'${mvnHome}/bin/mvn' clean package "
} else {
mvnHome = tool 'Maven-windows'
bat(/"${mvnHome}\bin\mvn" clean package /)
}
}
Another way to do it is to use Jenkins Conditional build step plugin.
Create freestyle job
In Build Step select conditional step single or multiple.
In the Run? you can select execute shell
In Builder select invoke-top-level-maven-target and select maven-linux in maven version. Then you can configure maven goals and other steps
In Build Step on again select conditional step single or multiple.
In the Run? you can select execute windows batch command
In Builder select invoke-top-level-maven-target and select maven-window in maven version. Then you can configure maven goals and other steps

Configure your linux slaves:
Manage jenkins > manage nodes > %node > configure > Node properties
Then specify mvn and java located on your slave and fill in Tool ocations

Related

How to run SonarQube for Go code using Jenkins

I need to run SonarQube for Go code using Jenkins. Unfortunately, there is little information regarding this task.
I have found that the "sonar-project.properties" file should be created, for example:
sonar.projectKey=com.company.projectkey1
sonar.projectName=My Project Name
sonar.sources=.
sonar.exclusions=**/*_test.go,**/vendor/**
sonar.tests=.
sonar.test.inclusions=**/*_test.go
sonar.test.exclusions=**/vendor/**
But how to configure a Jenkins pipeline correctly? I found the following example, but I'm not sure if this is what I need
node {
stage('SCM') {
git '<my_path>.git'
}
stage('SonarQube analysis') {
def scannerHome = tool 'SonarScanner 4.0';
withSonarQubeEnv('My SonarQube Server') {
sh "${scannerHome}/bin/sonar-scanner"
}
}
}
Yes, that is correct.
In your Jenkins pipeline you just need to run sonnar-scanner - that is no different from other languages (see https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-jenkins/). Go language plugin comes with SonarQube so no need to install anything. Scanner will then pickup project configuration from sonar-project.properties in your project root and perform the analysis.
Your sonar-project.properties file seems like a copied example from SonarQube for Go page - you might want to do some adjustments depending on project layout (e.g. add sonar.inclusions=**/.*go). SonarQube should detect files are in Go automatically but you can also add sonar.language=go to that file to force it.
You don't mention if you run SonarQube locally or in cluster mode - but there should be little or no difference (probably adding server url and login to sonar-project.properties in case of cluster installation).
Note that go needs to be installed on scanner machines.

Set up Jenkins to run a specific maven command

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}".

Unable to set maven in groovy script

I am using groovy script in jenkins pipeline job and I need maven to execute my stage.
I do not have control of .profile as it is running on slave. I need to set the Maven in my groovy script so that I can run man clean compile.
maven is located at /opt/runtime/apache-maven-3.3.3/bin/mvn.
I am very new to groovy and want to know how to use this.
You can do something like this:
// Maven location
def mvnHome = tool name: 'maven 3_3_9', type: 'hudson.tasks.Maven$MavenInstallation'
env.MAVEN_HOME = mvnHome
// Begin Compile
stage concurrency: 1, name: 'compile'
sh '''${MAVEN_HOME}/bin/mvn clean compile'''
Please note that the tool name comes from the Maven configuration you have defined in the Global Tool Configuration page.

How to execute remote bat file using build step in TeamCity?

I have TeamCity installed on centos. I have only one Linux BuildAgent for now. My build configuration execute a maven script and using ant upload WAR artifact to Windows Server on FTP. After this step i have to execute BAT file on remote Windows Server. I read that i can do this using psexec/RemCom, but i can't understand how i can do this in TeamCity? Build Step or different Build Configuration should contain steps to execute psexec/RemCom or i can insert Build Step into existed Build Configuration?
Single build configuration could potentially consists of multiple build steps. Think of them as a actions you would like to do. So I suppose that right now you have a maven step in your build configuration. I would suggest you to add Command Line step, where you can do what ever you want -- it's like bash/batch script. You can put script contents directly to the build step, or you can write script and execute it.
But as you mentioned that you have CentOS, it could be you have to do extra configuration on the build agent for PsExec to be available.

Restricting which downstream builds are triggered on SNAPSHOT dependency

We have a Jenkins server, using jenkins-build-per-branch to sync from git whenever a (php or java) project has a valid pom.xml. We use maven versioning strategy to manage our artefacts, and git-flow as a branching strategy / tool. We also use the jenkins option "Build whenever a SNAPSHOT dependency is built" wherever possible.
The problem we have is when building a -SNAPSHOT artefact - all hell breaks loose and everything wants to build at once. (Building a 'develop' -SNAPSHOT causes all downstream 'feature' AND 'develop' branches to start)
Ideally we would like to find some way that we don't cross pollenate between feature and develop builds when jenkins launches downstream jobs.
Has anyone tried this? Would something like the Conditional+BuildStep+Plugin help? https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
This is an old question but it's still relevant 6 years later. There is a "threshold" field on the Build whenever a SNAPSHOT dependency is built setting that provides some control over which builds will trigger
From the pipeline-maven-plugin README:
Threshold based on the Maven lifecycle phase reached in the Maven
build of the upstream job (package, install, deploy). By default, only
the maven builds who reach the deploy phase will trigger downstream
builds.
For example, in a scripted pipeline's withMaven() you can set a pipelineGraphPublisher with lifecycleThreshold: 'deploy' like:
withMaven(
maven: MAVEN_VERSION,
jdk: JAVA_VERSION,
mavenOpts: MAVEN_OPTS,
globalMavenSettingsConfig: globals.MAVEN_SETTINGS_ID,
options: [
pipelineGraphPublisher(
lifecycleThreshold: 'deploy',
includeSnapshotVersions: true
)
]) {
sh("mvn ${PHASE}")
}
Then any SNAPSHOT build that executes a lifecycle phase below deploy (e.g. package or install) will not trigger a downstream job. Note that deploy is already the default so this example isn't particularly useful, but it shows how to use the setting and you may want to set this to another phase.
That's part one done, but now you need a way to conditionally execute different Maven lifecycle phases for the builds that you do want to trigger downstream builds vs. the ones that you don't want to trigger downstream builds. We do this based on the branch name so that Pull Request and Release branches don't trigger upstream packages:
/**
* Return the correct Maven goal for the current branch
*
* Because the pipelineGraphPublisher's lifecycleThreshold in the withMaven() call above is set to 'deploy', pipelines
* that run the 'install' goal will not trigger downstream jobs; this helps us minimize superfluous Jenkins builds:
*
* https://github.com/jenkinsci/pipeline-maven-plugin/blob/master/README.adoc#trigger-downstream-pipeline-when-a-snapshot-is-built
*/
String getGoalForCurrentBranch() {
if ( env.BRANCH_NAME ==~ /(^PR-(\d+)$)|(^releases\/v.*)/ ) {
echo("Pull Request or release branch detected! Executing Maven 'install' goal rather than 'deploy' goal to avoid triggering downstream Jenkins jobs")
return 'install'
}
return 'deploy'
}
You can then call this getGoalForCurrentBranch() method wherever you're executing mvn to determine which lifecycle phase is executed:
withMaven(
...
sh("mvn ${getGoalForCurrentBranch()}")
)
Most branches will execute mvn deploy and will trigger a downstream Jenkins job, but Pull Request branches will execute mvn install and will not trigger a downstream job.
The caveat to this is that you may have other things that depend on certain lifecycle phases. In the above example, Pull Request branch artifacts won't get deployed to your artifact repository (e.g. Nexus). In our case this is actually the desired behavior but you'll need to determine what's acceptable for you and tweak your threshold accordingly.
In the dependent projects you can disable the "Build whenever a SNAPSHOT dependency is built" hook via
if (branchName.indexOf("mule4auto") >= 0) {
println "for mule4auto do not build when mulestac is build";
// for mule4auto do not build when mulestac is build, wait for
// mule4auto-converter project has run (commited something).
} else {
tempPipelineTriggers += [
snapshotDependencies()
];
}
println "triggers: tempPipelineTriggers=${tempPipelineTriggers}";
Additionally you may need to disable the fingerprint for the specific branches which should not be build (mule4auto in our case):
// see https://github.com/jenkinsci/pipeline-maven-plugin/blob/master/README.adoc
def tempMavenOptions = [];
// disable Archiving (fingerprinting should still work)
tempMavenOptions += artifactsPublisher(disabled: true);
if (branchName.indexOf("mule4auto") >= 0) {
println "Disable fingerprint for mule4auto to prevent jobs building when mulestac4 SNAPSHOT is build";
tempMavenOptions += dependenciesFingerprintPublisher(disabled: true);
tempMavenOptions += pipelineGraphPublisher(disabled: true);
}
// see https://plugins.jenkins.io/pipeline-maven
withMaven(
// Maven installation declared in the Jenkins "Global Tool Configuration"
maven: toolMaven,
jdk: toolJdkToBeUsed,
options: tempMavenOptions
) {
println "JAVA_HOME ${JAVA_HOME}";
println "MAVEN_HOME ${MAVEN_HOME}";
....
})
(both in destination pipeline)
I do not see an option like "Build whenever an upstream dependency is built" in our Jenkin's jobs. It's called "Build whenever a SNAPSHOT dependency is built" here (Jenkins v1.592 with its latest plugins). Is that what you mean?
There's also this last sentence in its inline help: "If this behavior is problematic, uncheck this option." :-)
I don't know whether Conditional BuildStep Plugin would help in this case. We use it but not to achieve such.
Depending on how long your jobs run I'd suggest to:
use the Build whenever ... in conjunction with Advanced Project Options → Quiet period if the jobs don't run long (let's say a few minutes)
deactivate the build-whenever-all-and-everywhere as suggested and use Post-build Actions → Build other projects or Trigger parameterized build on other project to establish a real up-/downstream build flow if your jobs run longer

Resources