Getting the real Jenkins job status for a pipeline job.

[Dallas Clement]

I have setup a declarative Jenkinsfile for my project.  I have some post conditions defined for success and failure.  I would like to be able to determine the job status for the previous build within the 'success' block so that  I can know if this success is a recovery from a previous failure.  I do understand that the currentBuild.result variable can be set at various stages and that the previous build result is available through currentBuild.getPreviousBuild()?.getResult().  But this previous build result seems to require the setting of currentBuild.result.

At this point, I am more interested in accessing the actual Jenkins job status, i.e. whatever it uses to determine whether a job has been a success or failure and not rely on currentBuild.result.  Is there some other variable available for this?

[Victor Martinez]

Hey Dallas,

Cannot you just use the changed condition https://jenkins.io/doc/book/pipeline/syntax/#post? Then you can use the http://javadoc.jenkins.io/plugin/workflow-support/org/jenkinsci/plugins/workflow/support/steps/build/RunWrapper.html#resultIsBetterOrEqualTo-java.lang.String-

See the below snippet:

...

    post {

        changed {

            script { 
                // http://javadoc.jenkins.io/plugin/workflow-support/org/jenkinsci/plugins/workflow/support/steps/build/RunWrapper.html#resultIsBetterOrEqualTo-java.lang.String-

                if (currentBuild.resultIsBetterOrEqualTo('SUCCESS')) {

                    echo "Previous build failed ${currentBuild?.getPreviousBuild()?.number} and now it has been fixed"

                }

            }

        }

    }

... 

Cheers

[Dallas Clement]

Victor, thanks for the help here.  I have played with the 'changed' action and also currentBuild.result and currentBuild?.getPreviousBuild(), but it looks like this variable is null unless explicitly set in one of the pipeline stages.  What I really want is the status Jenkins uses to determine which post condition is applicable, i.e. success, failure, etc.  It knows somehow, presumably based on $? values from each step.

[Victor Martinez]

As far as I see "currentBuild.getCurrentResult()" is not null even though when no set was explicitly set, this is my snippet and console output

pipeline {

    agent any

    stages {

        stage ('release') {

            steps {

                script {

                    echo "echo currentbuild ${BUILD_ID}"

                    //sh 'exit 1'

                }

            }

        }

    }

    post {

        changed {

            script {

                echo "${currentBuild.getCurrentResult()}"

                if (currentBuild.resultIsBetterOrEqualTo('SUCCESS')) {

                    echo "Previous build failed ${currentBuild?.getPreviousBuild()?.number} and now it has been fixed"

                }

            }

        }

    }

}

[Pipeline] node
Running on master in /var/jenkins_home/workspace/_scratch/test_def
[Pipeline] {
[Pipeline] stage
[Pipeline] { (release)
[Pipeline] script
[Pipeline] {
[Pipeline] echo
echo currentbuild 37
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Declarative: Post Actions)
[Pipeline] script
[Pipeline] {
[Pipeline] echo
SUCCESS
[Pipeline] echo
Previous build failed 36 and now it has been fixed
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS

Cheers

[Dallas Clement]

Victor, you are sure right.  This works like a champ!  Thank you very much.  Do you know if it's possible to get the status for each stage in a pipeline?

[Victor Martinez]

Unfortunately, I'm also asking a kind of similar question:

- https://groups.google.com/forum/#!topic/jenkinsci-users/9UYN8FZL35k

I haven't worked out how to do it without creating variables specifically per stage

[Slide]

You could do this with a map

Map stageResults = [:]

stage('Foo') {

    stageResults['Foo'] = Result.FAILURE

}

stage('Bar') {

   stageResults['Bar'] = Result.SUCCESS

}

Not ideal, but should work.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ce3fbe5c-df26-471c-a804-1d6643650b9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dallas Clement]

Thanks for these helpful ideas.  Seems like this would work fine.   One last related question:  How dost one trigger the 'unstable' condition in the pipeline post section?

[James Dumay]

We are working right now on making sure steps, stages, etc having individual statuses, a method for setting them at a stage/parallel level instead of for the whole pipeline and to introduce  consistent behaviour for those statuses in the Blue Ocean pipeline visualisation. 

You can check the status for this on the roadmap "Unstable stages, parallels and steps"

The tickets to watch are:

* JENKINS-39203 will make all the statuses consistent, remove unstable setting the whole pipeline to unstable  

* JENKINS-45579 will allow you to set a stage to "unstable" using a special step (similar to the error step)

If you have any other use cases in mind, please open a new ticket describing your problem. If you can describe your problem with a mock Jenkinsfile and a drawing of your desired visualization that helps narrow things down even further :)

[James Dumay]

Oh, and if your use case is covered by an existing ticket, providing us with more context (like I described for new tickets) as a comment would be fantastic.

[Dallas Clement]

Hi James.  This sounds like a dream come true to have status for individual stages and steps.  In my particular situation I need to collect test results from a lot of bash scripts and somehow tally failure counts and report them back for each individual test.  Will have to think some more about that and perhaps open a new ticket describing what I need.  Thanks for the help.

[James Dumay]

Thats great to hear, Dallas! 

We are also making a change so that you can see from the test reporting screen which stage and parallel was responsible for the test result. See JENKINS-46166.

 Without going into details, the underlying work we need to do for all of these things is highly related.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/3nWDhDOPrE4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/d93a3cf6-1eca-4d67-80cd-16d38eef01f8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

James Dumay,
Director of Product Management.
CloudBees, Inc.

Skype: jdumaycb Twitter: i386

Meet with me: https://calendly.com/jdumay

[Dallas Clement]

James, how soon do you think these changes will come to fruition?  Looking at the Jira issues you noted, I got the impression it might be a while.

[James Dumay]

Hopefully before the year is out. It's hard to say. We are focused on getting things right once than doing it quickly.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/3b4ee108-9ecf-4977-a1a3-d3c1cecea0b4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.