I have problem with method waitForQualityGate(). I got an error "No such DSL method 'waitForQualityGate' found among steps". Another strange thing is that I must use parameter -DX for sonarscanner. I don't know what is wrong. Thanks for help.
pipeline {
agent { label 'builders' }
tools {
maven 'maven 3.3.9'
}
stages {
stage ('Checkout'){
steps {
git branch: 'develop', credentialsId: 'credential', url: 'ssh://repository'
}
}
stage ('Build'){
steps {
withMaven (
maven: 'maven 3.3.9',
mavenSettingsConfig: 'cc86690e-095d-4714-92b2-b61861241c7a'){
sh 'mvn -U clean package -DskipTests'
}
}
}
stage ('SonarQube Scan'){
steps {
withSonarQubeEnv('SonarQube') {
withMaven (
maven: 'maven 3.3.9',
mavenSettingsConfig: 'cc86690e-095d-4714-92b2-b61861241c7a'){
sh 'mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.3.0.603:sonar ' +
'-DX' +
'-Dsonar.login=login' +
'-Dsonar.password=password' +
'-Dsonar.issuesReport.json.enable=true' +
'-Dsonar.report.export.path=sonar-report.json'
}
} // SonarQube taskId is automatically attached to the pipeline context
}
}
stage ('Quality Gate') {
steps {
timeout(time: 1, unit: 'HOURS') { // Just in case something goes wrong, pipeline will be killed after a timeout
script {
def qg = waitForQualityGate() // Reuse taskId previously collected by withSonarQubeEnv
if (qg.status != 'OK') {
error "Pipeline aborted due to quality gate failure: ${qg.status}"
}
}
}
}
}
}
}
This will not be an immediate answer, but the reason for the error is, you are calling a custom method without even loading it initially. Load the groovy file that have the method, which jenkins is complaining that dsl doesn't exist... only when you load the groovy file/the class, then you can instantiate it.
Cannot do this, without loading it ... def qg = waitForQualityGate()
If its a method, u have to call it and it should return something...
Related
I have a pipeline with stages where one of the stages, intermittently takes longer than expected and hence using timeout to abort it. But if the stage is aborted, build also marked as aborted. Following is the code for the pipeline:
pipeline {
agent any
stages {
stage('First') {
options {
timeout(time: 10, unit: 'SECONDS')
}
steps {
script {
catchError(buildResult: 'SUCCESS') {
echo "Executing stage I"
sleep 12
}
}
}
}
stage('Second') {
steps {
script {
echo "Executing stage II"
}
}
}
}
}
Even though the stage is marked as Aborted, I want to mark build as Success. Can you please help how I can achieve this?
I would suggest one improvement to Michael's answer (which is correct btw). You can use catchError to mark stage ABORTED (or UNSTABLE) and mark the build SUCCESS, but you need to wrap the code that may timeout with try-catch block to control the error. Consider the following example:
pipeline {
agent any
stages {
stage('First') {
options {
timeout(time: 3, unit: 'SECONDS')
}
steps {
script {
catchError(buildResult: 'SUCCESS', stageResult: 'ABORTED') {
try {
echo "Executing stage I"
sleep 4
} catch(org.jenkinsci.plugins.workflow.steps.FlowInterruptedException e) {
error "Stage interrupted with ${e.toString()}"
}
}
}
}
}
stage('Second') {
steps {
script {
echo "Executing stage II"
}
}
}
}
}
When you run this pipeline, the stage that timed out is marked as ABORTED, but the pipeline continues and if there is no failure in the remaining stages, it is marked as SUCCESS.
And here is what the UNSTABLE stage status looks like.
Michael's solution works as well, but it produces a slightly different result - the stage that times out is marked as SUCCESS, and this might be less intuitive. You need to click on the stage to check if it timed out or not.
pipeline {
agent any
stages {
stage('First') {
options {
timeout(time: 3, unit: 'SECONDS')
}
steps {
script {
try {
echo "Executing stage I"
sleep 4
} catch(Exception e) {
currentBuild.result = "SUCCESS"
}
}
}
}
stage('Second') {
steps {
script {
echo "Executing stage II"
}
}
}
}
}
Your catchError() won't work in your case. The documantation (Source) tells the following:
buildResult (optional)
If an error is caught, the overall build result
will be set to this value. Note that the build result can only get
worse, so you cannot change the result to SUCCESS if the current
result is UNSTABLE or worse. Use SUCCESS or null to keep the build
result from being set when an error is caught.
The build status is set with currentBuild.currentResult which can have three values: SUCCESS, UNSTABLE, or FAILURE.
If you want to mark the build as SUCCESS on abortion the post-option (Source) aborted can be used:
pipeline {
agent any
stages {
stage('Example') {
steps {
echo 'Hello World'
}
}
}
post {
aborted {
// Executed only if stage is aborted
currentBuild.result = 'SUCCESS'
}
}
}
We have a situation where JDK1.7 is used to compile a project and JDK1.8 is used in sonar pipeline job on the aforementioned compiled code.
Is it possible to use 2 JDKs in a single scripted job. If sonar stage is reached, then JDK 1.8 must be used.
Currently this is our pipeline.
node('jenkins_uat_sdg_1g'){
env.JAVA_HOME="${tool 'JDK1.7_110'}"
env.PATH="${env.JAVA_HOME}/bin:${env.PATH}"
deleteDir()
try{
try{
stage('SCM Code Checkout'){
echo "Checking out source code from SVN..."
echo "successfully checked out from SVN"
}
} catch(error){
println("Unable to checkout...there were some errors!")
currentBuild.result = "FAILURE"
error()
}
try{
stage('Compile & Package Generation'){
echo "Begining to compile the code"
bat label: 'build-maven', script: 'mvn -f pom.xml clean compile install'
echo "Successfully compiled"
}
}catch(error){
println("Unable to compile...there were some errors!")
currentBuild.result = "FAILURE"
error()
}
}
Different pipeline script is used for sonar analysis.
node('jenkins_uat_sdg_1g'){
env.JAVA_HOME="${tool 'JDK1.8'}"
env.PATH="${env.JAVA_HOME}/bin:${env.PATH}"
stage('SCM Code Checkout'){
echo "Checking out source code from SVN..."
echo "successfully checked out from SVN"
}
stage('sonarqube analysis'){
withSonarQubeEnv('SonarServer'){
bat label: 'sonar-analyis', script: '"D:/Apache Build Tools/apache-maven-3.6.1-bin/apache-maven-3.6.1/bin/mvn" org.sonarsource.scanner.maven:sonar-maven-plugin:3.6.0.1398:sonar -f parent/pom.xml -Dsonar.host.url=http://10.xx.xx.xx:9500 -Dsonar.login=xxxxxxxxxxxxxxxxxxxxxa4b4cf180c6'
}
}
}
stage('Quality Gate'){
timeout(time: 5, unit: 'MINUTES'){
def qg = waitForQualityGate()
if(qg.status != 'OK'){
error "Pipeline aborted due to quality gate failure: ${qg.status}"
}
}
}
Is it possible to have a single script which utilizes two JDKs in a single job.
Regards
You can make use of withEnv step to set one or more environment variables within a block. These are available to any external processes spawned within that scope
The following code works for me where i am accessing different Java versions in different stages:
node('slave1') {
deleteDir()
try {
try {
stage('During Build') {
withEnv(['JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin']) {
sh '${JAVA_HOME}/java -version'
println("or whatever command you want to run in this block...")
}
}
} catch(error) {
println("Unable to find Java 7!")
currentBuild.result = "FAILURE"
error()
}
try {
stage('During Sonar Analysis') {
withEnv(['JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin']) {
sh '${JAVA_HOME}/java -version'
println("or whatever command you want to run in this block...")
}
}
} catch(error) {
println("Unable to find Java 8!")
currentBuild.result = "FAILURE"
error()
}
} catch(error) {
println("Last catch block!")
error()
}
}
Note: As you would have noticed above, we are using single quotes in Groovy, so the variable expansion is being done by the Bourne shell, not Jenkins
Output:
I am executing in a pipeline a command to pass the sound of a project, what I need is that, just like in a normal job the sonar link remains once the job is executed, the same happens in the pipeline, now that when I run it in the pipeline, the SonarQube link is not saved, so I have the steps in groovy:
stage ('QA'){
steps {
echo 'executing sonar'
bat 'mvn sonar:sonar -Dsonar.host.url='+env.SONAR_URL+' -
Dsonar.projectName=QA:%JOB_BASE_NAME% -
Dsonar.projectKey=QA:%JOB_BASE_NAME%'
}
}
stage("Quality Gate"){
timeout(time: 1, unit: 'HOURS') { // Just in case something goes wrong, pipeline will be killed after a timeout
def qg = waitForQualityGate() // Reuse taskId previously collected by withSonarQubeEnv
if (qg.status != 'OK') {
error "Pipeline aborted due to quality gate failure: ${qg.status}"
}
}
}
Try replacing with:
stage ('QA'){
steps {
echo 'Running SonarQube..'
withSonarQubeEnv('XXXXXXXX') {
bat 'mvn sonar:sonar -Dsonar.host.url='+env.SONAR_URL+' -
Dsonar.projectName=QA:%JOB_BASE_NAME% -
Dsonar.projectKey=QA:%JOB_BASE_NAME%'
timeout(time: 1, unit: 'HOURS') {
script {
def qg = waitForQualityGate()
if (qg.status != 'OK') {
error "Pipeline aborted due to a quality gate failure: ${qg.status}"
}
}
}
}
}
}
Note that the XXXXXXXX should be replaced with the name of a Sonar config you've entered in Jenkins under Manage Jenkins>Configure System>SonarQube servers
As far as declarative pipelines go in Jenkins, I'm having trouble with the when keyword.
I keep getting the error No such DSL method 'when' found among steps. I'm sort of new to Jenkins 2 declarative pipelines and don't think I am mixing up scripted pipelines with declarative ones.
The goal of this pipeline is to run mvn deploy after a successful Sonar run and send out mail notifications of a failure or success. I only want the artifacts to be deployed when on master or a release branch.
The part I'm having difficulties with is in the post section. The Notifications stage is working great. Note that I got this to work without the when clause, but really need it or an equivalent.
pipeline {
agent any
tools {
maven 'M3'
jdk 'JDK8'
}
stages {
stage('Notifications') {
steps {
sh 'mkdir tmpPom'
sh 'mv pom.xml tmpPom/pom.xml'
checkout([$class: 'GitSCM', branches: [[name: 'origin/master']], doGenerateSubmoduleConfigurations: false, submoduleCfg: [], userRemoteConfigs: [[url: 'https://repository.git']]])
sh 'mvn clean test'
sh 'rm pom.xml'
sh 'mv tmpPom/pom.xml ../pom.xml'
}
}
}
post {
success {
script {
currentBuild.result = 'SUCCESS'
}
when {
branch 'master|release/*'
}
steps {
sh 'mvn deploy'
}
sendNotification(recipients,
null,
'https://link.to.sonar',
currentBuild.result,
)
}
failure {
script {
currentBuild.result = 'FAILURE'
}
sendNotification(recipients,
null,
'https://link.to.sonar',
currentBuild.result
)
}
}
}
In the documentation of declarative pipelines, it's mentioned that you can't use when in the post block. when is allowed only inside a stage directive.
So what you can do is test the conditions using an if in a script:
post {
success {
script {
if (env.BRANCH_NAME == 'master')
currentBuild.result = 'SUCCESS'
}
}
// failure block
}
Using a GitHub Repository and the Pipeline plugin I have something along these lines:
pipeline {
agent any
stages {
stage('Build') {
steps {
sh '''
make
'''
}
}
}
post {
always {
sh '''
make clean
'''
}
success {
script {
if (env.BRANCH_NAME == 'master') {
emailext (
to: 'engineers#green-planet.com',
subject: "${env.JOB_NAME} #${env.BUILD_NUMBER} master is fine",
body: "The master build is happy.\n\nConsole: ${env.BUILD_URL}.\n\n",
attachLog: true,
)
} else if (env.BRANCH_NAME.startsWith('PR')) {
// also send email to tell people their PR status
} else {
// this is some other branch
}
}
}
}
}
And that way, notifications can be sent based on the type of branch being built. See the pipeline model definition and also the global variable reference available on your server at http://your-jenkins-ip:8080/pipeline-syntax/globals#env for details.
Ran into the same issue with post. Worked around it by annotating the variable with #groovy.transform.Field. This was based on info I found in the Jenkins docs for defining global variables.
e.g.
#!groovy
pipeline {
agent none
stages {
stage("Validate") {
parallel {
stage("Ubuntu") {
agent {
label "TEST_MACHINE"
}
steps {{
sh "run tests command"
recordFailures('Ubuntu', 'test-results.xml')
junit 'test-results.xml'
}
}
}
}
}
post {
unsuccessful {
notify()
}
}
}
// Make testFailures global so it can be accessed from a 'post' step
#groovy.transform.Field
def testFailures = [:]
def recordFailures(key, resultsFile) {
def failures = ... parse test-results.xml script for failures ...
if (failures) {
testFailures[key] = failures
}
}
def notify() {
if (testFailures) {
... do something here ...
}
}
With jenkins build flow plugin this was possible:
ignore(FAILURE){
build( "system-check-flow" )
}
How to do this with Declarative Pipeline syntax?
To ignore a failed step in declarative pipeline you basically have two options:
Use script step and try-catch block (similar to previous proposition by R_K but in declarative style)
stage('someStage') {
steps {
script {
try {
build job: 'system-check-flow'
} catch (err) {
echo err.getMessage()
}
}
echo currentBuild.result
}
}
Use catchError
stage('someStage') {
steps {
catchError {
build job: 'system-check-flow'
}
echo currentBuild.result
}
}
In both cases the build won't be aborted upon exception in build job: 'system-check-flow'. In both cases the echo step (and any other following) will be executed.
But there's one important difference between these two options. In first case if the try section raises an exception the overall build status won't be changed (so echo currentBuild.result => SUCCESS). In the second case you overall build will fail (so echo currentBuild.result => FAILURE).
This is important, because you can always fail the overall build in first case (by setting currentBuild.result = 'FAILURE') but you can't repair build in second option (currentBuild.result = 'SUCCESS' won't work).
In addition to simply making the stage pass, it is now also possible to fail the stage, but continue the pipeline and pass the build:
pipeline {
agent any
stages {
stage('1') {
steps {
sh 'exit 0'
}
}
stage('2') {
steps {
catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
sh "exit 1"
}
}
}
stage('3') {
steps {
sh 'exit 0'
}
}
}
}
In the example above, all stages will execute, the pipeline will be successful, but stage 2 will show as failed:
As you might have guessed, you can freely choose the buildResult and stageResult, in case you want it to be unstable or anything else. You can even fail the build and continue the execution of the pipeline.
Just make sure your Jenkins is up to date, since this feature is only available since "Pipeline: Basic Steps" 2.16 (May 14, 2019). Before that, catchError is still available but without parameters:
steps {
catchError {
sh "exit 1"
}
}
I was looking for an answer for a long time and I found a hack for it! I put the try/catch block on the whole stage:
try {
stage('some-stage') {
//do something
}
} catch (Exception e) {
echo "Stage failed, but we continue"
}
try {
stage("some-other-stage") { // do something }
} catch (Exception e) {
echo "Stage failed, but we still continue"
}
As result you will get something like this:
This is still not ideal, but it gives the necessary results.
In recent versions it's possible to pass propogate=false option to build step.
link:
https://jenkins.io/doc/pipeline/steps/pipeline-build-step/
example:
build job:"jobName", propagate:false
Try this example:
stage('StageName1')
{
steps
{
catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE')
{
SomeCodeThatCanBeErrored
}
}
}
stage('StageName2')
{
steps
{
ContinueOtherCode
}
}
For my decalartive pipeline I have found another solution:
stage('Deploy test')
{
steps
{
bat returnStatus: true, script: 'sc stop Tomcat9'
// The return value of the step will be the status code!
// evaluate return status yourself, or ignore it
}
}
The same works for the sh command to execute scripts on Unix platforms.
The example ignores the return status, because the tomcat might be already stopped, because of a previously failed pipeline run.
In the new pipeline, you can use try-catch to achieve this.
node{
try{
build job: 'system-check-flow'
}
catch (err){
echo "system-check-flow failed"
}
try{
build job: 'job2'
}
catch (err){
echo "job2 failed"
}
}
Here it will build the 'system-check-flow' job. If it fails it will catch the error, ignore, and then move on to build 'job2'
See this post for a full discussion.
pipeline {
agent any
stages {
stage('Stage') {
steps{
script{
jobresult = build(job: './failing-job',propagate:false).result
if(jobresult != 'SUCCESS'){
catchError(stageResult: jobresult, buildResult: 'UNSTABLE'){
error("Downstream job failing-job failed.")
}
}
}
}
}
}
}
For all those that are wondering about how to set the result of a downstream job to the stage/build) Not the most graceful solution, but it gets the job done. Funny thing is that if this stageResult variable was available as a global variable or as a variable outside the catchError block these kinds of solutions would not be needed. Sadly it isn't, and the only way to set the stage result in a pipeline that I thought of is this way. The error() block is needed, otherwise catchError will not set the stageResult/buildResult(the catchError block requires an error, ofcourse).
Complementing the existing working solutions that use catchError as a step or in script, you can also use catchError as a stage option.
This is useful if you have multiple sub stages that you want to catch errors for in the parent stage:
pipeline {
agent any
stages {
stage('Tests') {
options {
catchError(message: "Test failed", stageResult: 'UNSTABLE', buildResult: 'UNSTABLE')
}
stages {
stage('Test 1') {
echo 'test 1 succeeded'
}
stage('Test 2') {
error 'test 2 failed'
}
}
}
}
}
This isn't explicitly documented, but there is a hint that you may use steps as options (emphasis mine):
However, the stage-level options can only contain steps like retry,
timeout, or timestamps, or Declarative options that are relevant to a
stage, like skipDefaultCheckout.
It names a few steps as examples, but not as the only possible steps to be used as options. Also, if you enter an invalid option, Jenkins lists all available options in the error message, which includes catchError.
The cleanest and latest way would be:
stage('Integration Tests') {
steps {
script {
warnError(message: "${STAGE_NAME} stage was unstable.", catchInterruptions: false) {
// your scripts
}
}
}
}
Reference: https://www.jenkins.io/doc/pipeline/steps/workflow-basic-steps/#warnerror-catch-error-and-set-build-and-stage-result-to-unstable
you could put the step script inside "post" step, if if it's a teardown like step
code as below:
post {
always {
script {
try{
echo 'put your alway need run scripts here....if it's a teardown like step'
}catch (err) {
echo 'here failed'
}
script{
emailext (
xxxx
)
}
}