[JIRA] (JENKINS-56402) Declarative Pipeline shows SUCCESS even though job FAILED

15 views
Skip to first unread message

gp@gpcentre.net (JIRA)

unread,
Mar 4, 2019, 5:56:02 PM3/4/19
to jenkinsc...@googlegroups.com
Philip Zozobrado created an issue
 
Jenkins / Bug JENKINS-56402
Declarative Pipeline shows SUCCESS even though job FAILED
Issue Type: Bug Bug
Assignee: Unassigned
Components: pipeline
Created: 2019-03-04 22:55
Environment: Jenkins 2.150.3, using a slave build executioner
Labels: jenkins pipeline post-actions results status
Priority: Major Major
Reporter: Philip Zozobrado

Pipelines are "failing" with SUCCESS status. 

This pipeline, taken from JENKINS-46325 illustrates this issues successfully:

pipeline {
    agent any
    stages {
        stage ('Init') {
            steps {
                echo "Init result: ${currentBuild.result}"
                echo "Init currentResult: ${currentBuild.currentResult}"
            }
            post {
                always {
                    echo "Post-Init result: ${currentBuild.result}"
                    echo "Post-Init currentResult: ${currentBuild.currentResult}"
                }
            }
        }
        stage ('Build') {
            steps {
                echo "During Build result: ${currentBuild.result}"
                echo "During Build currentResult: ${currentBuild.currentResult}"
                sh 'exit 1'
            }
            post {
                always {
                    echo "Post-Build result: ${currentBuild.result}"
                    echo "Post-Build currentResult: ${currentBuild.currentResult}"
                }
            }
        }
    }
    post {
        always {
            echo "Pipeline result: ${currentBuild.result}"
            echo "Pipeline currentResult: ${currentBuild.currentResult}"
        }
    }
}

 

My results are (trimmed down):

Running on build-096575a3-e6af-4fff-9ca1-84cc46ba4b86-f9b8d29c in /var/vcap/data/jenkins-slave/workspace/test-job
Init result: null
Init currentResult: SUCCESS
Post stage
Post-Init result: null
Post-Init currentResult: SUCCESS
During Build result: null
During Build currentResult: SUCCESS
[Pipeline] sh
+ exit 1
Post stage
Post-Build result: null
Post-Build currentResult: SUCCESS
Pipeline result: null
Pipeline currentResult: SUCCESS
ERROR: script returned exit code 1
Finished: FAILURE

 
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 11:01:03 AM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado updated an issue
Change By: Philip Zozobrado
Pipelines are "failing" with SUCCESS status. 

This pipeline, taken from JENKINS-46325 illustrates this issues issue successfully:
{code :java }

pipeline {
    agent any
    stages {
        stage ('Init') {
            steps {
                echo "Init result: ${currentBuild.result}"
                echo "Init currentResult: ${currentBuild.currentResult}"
            }
            post {
                always {
                    echo "Post-Init result: ${currentBuild.result}"
                    echo "Post-Init currentResult: ${currentBuild.currentResult}"
                }
            }
        }
        stage ('Build') {
            steps {
                echo "During Build result: ${currentBuild.result}"
                echo "During Build currentResult: ${currentBuild.currentResult}"
                sh 'exit 1'
            }
            post {
                always {
                    echo "Post-Build result: ${currentBuild.result}"
                    echo "Post-Build currentResult: ${currentBuild.currentResult}"
                }
            }
        }
    }
    post {
        always {
            echo "Pipeline result: ${currentBuild.result}"
            echo "Pipeline currentResult: ${currentBuild.currentResult}"
        }
    }
}
{code}

 

My results are (trimmed down):
{noformat}

Running on build-096575a3-e6af-4fff-9ca1-84cc46ba4b86-f9b8d29c in /var/vcap/data/jenkins-slave/workspace/test-job
Init result: null
Init currentResult: SUCCESS
Post stage
Post-Init result: null
Post-Init currentResult: SUCCESS
During Build result: null
During Build currentResult: SUCCESS
[Pipeline] sh
+ exit 1
Post stage
Post-Build result: null
Post-Build currentResult: SUCCESS
Pipeline result: null
Pipeline currentResult: SUCCESS
ERROR: script returned exit code 1
Finished: FAILURE
{noformat}
 

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 5, 2019, 1:39:02 PM3/5/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor commented on Bug JENKINS-56402
 
Re: Declarative Pipeline shows SUCCESS even though job FAILED

I'm experiencing the same. currentBuild.currentResult for all failed and aborted builds returns "SUCCESS". Same when using $BUILD_STATUS through the emailext plugin.

Using Jenkins version 2.150.3 and Pipeline 2.6. All pipeline related plugins are at the latest version as well.

 

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 2:17:02 PM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado updated an issue
Change By: Philip Zozobrado
Environment: Jenkins 2.150.3, Pipeline 2.6, using a slave build executioner

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 5, 2019, 2:50:02 PM3/5/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
I'm experiencing the same. {{currentBuild.currentResult}} for all failed and aborted builds returns "SUCCESS". Same when using {{$BUILD_STATUS}} through the {{emailext}} plugin.

Using Jenkins version 2.150.3 and Pipeline 2.6. All pipeline related plugins are at the latest version as well.

*EDIT*: I investigated this issue and looks like it introduced by the {{Pipeline: Declarative}} plugin v1.3.5. The offending commit seems to be [ https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/ 39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a|https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a].

{color:#00875a}*Downgrading to v1.3.4.1 is the workaround for now.*{color}

 

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 5, 2019, 2:50:03 PM3/5/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
I'm experiencing the same. {{currentBuild.currentResult}} for all failed and aborted builds returns "SUCCESS". Same when using {{$BUILD_STATUS}} through the {{emailext}} plugin.

Using Jenkins version 2.150.3 and Pipeline 2.6. All pipeline related plugins are at the latest version as well.
*EDIT*: I investigated this issue and looks like it introduced by the   {{Pipeline: Declarative}} plugin v1.3.5. The offending commit seems to be [39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a|https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a].


{color:#00875a}*Downgrading to v1.3.4.1 is the workaround for now.*{color}

 

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 5, 2019, 2:54:01 PM3/5/19
to jenkinsc...@googlegroups.com

I investigated this issue and looks like it introduced by the Pipeline: Declarative plugin v1.3.5. The offending commit seems to be https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a.

Downgrading to v1.3.4.1 is the workaround for now.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 5, 2019, 2:54:02 PM3/5/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
I'm experiencing the same. {{currentBuild.currentResult}} for all failed and aborted builds returns "SUCCESS". Same when using {{$BUILD_STATUS}} through the {{emailext}} plugin.

Using Jenkins version 2.150.3 and Pipeline 2.6. All pipeline related plugins are at the latest version as well.


*EDIT*: I investigated this issue and looks like it introduced by the {{Pipeline: Declarative}} plugin v1.3.5. The offending commit seems to be [https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a|https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a].

{color:#00875a}*Downgrading to v1.3.4.1 is the workaround for now.*{color}

 

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 3:01:02 PM3/5/19
to jenkinsc...@googlegroups.com

^^ I can confirm, symptoms arise upgrading to 1.3.5. I updated an older Jenkins to 1.3.5 and it resulted in the same symptoms. Downgrading back to 1.3.4.1 resolved it.

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 5, 2019, 3:07:02 PM3/5/19
to jenkinsc...@googlegroups.com
Devin Nusbaum updated an issue
 
Change By: Devin Nusbaum
Component/s: pipeline-model-definition-plugin
Component/s: pipeline

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 5, 2019, 3:07:02 PM3/5/19
to jenkinsc...@googlegroups.com
Devin Nusbaum commented on Bug JENKINS-56402
 
Re: Declarative Pipeline shows SUCCESS even though job FAILED

Lakshya Kapoor Yes, this is caused by PR 313, which was the fix for JENKINS-55459. In general, you cannot use currentBuild.result to accurately determine the current state of the build, because currentBuild.result does not take into account any in-flight exceptions that are propagating throughout the execution and will cause it to result in failure at the top-level. Post conditions in Declarative do account for these in-flight exceptions and should be triggered appropriately. Getting and/or setting the build result is somewhat messy in Scripted Pipeline as well and does not always do what you want because there is no step-level build result, only an overall build result. The changes made in PR 313 made Declarative match the behavior of Scripted.

What is your actual use case? Can you use POST conditions without actually inspecting the build result? Perhaps we could provide some other kind of API visible to scripts to expose the ephemeral result that will be used when deciding what POST steps to run, but if you are setting the build result intentionally to try and change the flow of execution then I am not sure what we could do to fix that use case. CC Andrew Bayer

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 5, 2019, 3:13:02 PM3/5/19
to jenkinsc...@googlegroups.com
Devin Nusbaum edited a comment on Bug JENKINS-56402
[~kapoorlakshya] Yes, this is caused by [PR 313|https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/313], which was the fix for JENKINS-55459. In general, you cannot use {{currentBuild.result}} to accurately determine the current state of the build, because {{currentBuild.result}} does not take into account any in-flight exceptions that are propagating throughout the execution and will cause it to result in failure at the top-level. Post conditions in Declarative _do_ account for these in-flight exceptions and should be triggered appropriately. Getting and/or setting the build result is somewhat messy in Scripted Pipeline as well and does not always do what you want because there is no step-level build result, only an overall build result. The changes made in PR 313 made Declarative match the behavior of Scripted.

What is your actual use case? Can you use POST post conditions without actually inspecting the build result? Perhaps we could provide some other kind of API visible to scripts to expose the ephemeral result that will be used when deciding what POST steps to run, but if you are setting the build result intentionally to try and change the flow of execution then I am not sure what we could do to fix that use case. CC [~abayer]

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 3:17:02 PM3/5/19
to jenkinsc...@googlegroups.com

Devin Nusbaum Does all what you said also apply to `currentBuild.currentResult` ? It's also showing incorrectly on failed stages.

Can you use POST conditions without actually inspecting the build result?

I'd like to answer your question with another question: How do we get a build status when inspecting `currentBuild` if `result` and `currentResult` are both incorrect on a build failure?

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 3:18:02 PM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado edited a comment on Bug JENKINS-56402
[~dnusbaum] Does all what you said also apply to `currentBuild.currentResult` ? It's also showing incorrectly on failed stages.

{quote}

Can you use POST conditions without actually inspecting the build result?
{quote}


I'd like to answer your question with another question: How do we get a build status when inspecting `currentBuild` if `result` and `currentResult` are both incorrect on a build failure?


Wouldn't this also make `resultIsBetterOrEqualTo` and `resultIsWorseOrEqualTo` now moot since we can no longer rely on any build status checks?

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 3:19:03 PM3/5/19
to jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 5, 2019, 3:33:02 PM3/5/19
to jenkinsc...@googlegroups.com

Does all what you said also apply to currentBuild.currentResult

Yes, currentBuild.getCurrentResult() is identical to currentBuild.getResult() except for the fact that it defaults to SUCCESS instead of null if the build result has not yet been set, see the code here.

How do we get a build status when inspecting `currentBuild` if `result` and `currentResult` are both incorrect on a build failure?

As far as I am aware, there is no way in Declarative to get an accurate picture of the current build status using only currentBuild. In Scripted, I think you could use try/catch statements along with currentBuild to look at the current status and catch specific kinds of exceptions to handle status-conditional logic, essentially duplicating this logic in Declarative. In Declarative, you should be able to use post conditions to handle status-conditional logic without needing to use currentBuild directly. I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases.

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 3:47:02 PM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado edited a comment on Bug JENKINS-56402
{quote}

I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases.
{quote}

I use currentBuild extensively to get the build's information, following some examples from here: https://www.christopherrung.com/2017/05/04/slack-build-notifications/

It's a notification prettier to send Slack messages about the build's status at the point of success, failure, etc. While they don't directly use {{result}} in the code, we used POST {{ always { notifySlack(currentbuild.result) } }} as a catch-all for build statuses. {{currentBuild}} is, however, extensively used for grabbing test results and result details.

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 3:47:02 PM3/5/19
to jenkinsc...@googlegroups.com

I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases.

I use currentBuild extensively to get the build's information, following some examples from here: https://www.christopherrung.com/2017/05/04/slack-build-notifications/

It's a notification prettier to send Slack messages about the build's status at the point of success, failure, etc. While they don't directly use result in the code, we used POST {{ always

{ notifySlack(currentbuild.result) }

}} as a catch-all for build statuses. currentBuild is, however, extensively used for grabbing test results and result details.

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 3:48:03 PM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado edited a comment on Bug JENKINS-56402
{quote}

I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases.
{quote}


I use currentBuild extensively to get the build's information, following some examples from here: https://www.christopherrung.com/2017/05/04/slack-build-notifications/

It's a notification prettier to send Slack messages about the build's status at the point of success, failure, etc. While they don't directly use {{result}} in the code, we used POST

 { { code}
 always { notifySlack(currentbuild.result) }
{code } }
as a catch-all for build statuses. {{currentBuild}} is, however, extensively used for grabbing test results and result details.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 5, 2019, 4:58:02 PM3/5/19
to jenkinsc...@googlegroups.com

Hi Devin Nusbaum, my use case is similar to Philip Zozobrado's. I am sending an email notification in my post step (always) and I am using currentBuild.currentResult to determine the font color for the build status and the subject line in the email:

def statusColor = colorCodeByStatus(currentBuild.currentResult) // $BUILD_STATUS font color

...

// Returns HEX code based on given build status
def colorCodeByStatus(status) {
  if(status == 'SUCCESS') {
    '#28B463' // Green
    
  } else if(status == 'FAILURE') {
    '#DF0101' // Red

  } else { // Aborted or Unstable
    '#9E9E9E' // Gray
  }
}

I am not sure if this violates any sort of best practices, but this could be a workaround for such use cases:

post {
  success {
      currentBuild.currentResult = 'SUCCESS'
  }
  unstable {
      currentBuild.currentResult = 'UNSTABLE'
  }
  failure {
      currentBuild.currentResult = 'FAILURE'
  }
  always {
    dir(path: 'report') {
      executePostSteps(JOB_NAME)
    }
  }
} // post

I haven't had a chance to test it yet, so please feel free to critique it.

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 5:04:03 PM3/5/19
to jenkinsc...@googlegroups.com

Lakshya Kapoor, unfortunately, always runs first. That won't work:

The condition blocks are executed in the order shown below.
always, changed, fixed, regression, aborted, failure, success, unstable, unsuccessful, and cleanup.

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 5:06:02 PM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado edited a comment on Bug JENKINS-56402
[~kapoorlakshya], unfortunately, {{always}} runs first. That won't work:
* [https://jenkins.io/doc/book/pipeline/syntax/#post]

{quote}The condition blocks are executed in the order shown below.

always, changed, fixed, regression, aborted, failure, success, unstable, unsuccessful, and cleanup.
{quote}

There's also some fall-through not documented: {{fixed}} will _also_ run {{success}}, for example.

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 5:07:01 PM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado edited a comment on Bug JENKINS-56402
[~kapoorlakshya], unfortunately, {{always}} runs first. That won't work:
* [https://jenkins.io/doc/book/pipeline/syntax/#post]

{quote}The condition blocks are executed in the order shown below.
always, changed, fixed, regression, aborted, failure, success, unstable, unsuccessful, and cleanup.
{quote}

There's also some fall-through not documented: {{fixed}} will _also_ run {{success}}, for example.


I've updated my pipeline to:
{code}
        post {
            cleanup {
                cleanWs()
            }
            failure {
                notifySlack([status  : 'FAILURE',
                     pipeline: this] as JenkinsStatus)
            }
            fixed {
                notifySlack([status  : 'FIXED',
                     pipeline: this] as JenkinsStatus)
            }
            unstable {
                notifySlack([status  : 'UNSTABLE',
                     pipeline: this] as JenkinsStatus)
            }
            success {
                notifySlack([status  : 'SUCCESS',
                     pipeline: this] as JenkinsStatus)
            }
        }
{code}

However, I'm still looking for a way to kill the {{fixed}} fall-through.

gp@gpcentre.net (JIRA)

unread,
Mar 5, 2019, 5:08:02 PM3/5/19
to jenkinsc...@googlegroups.com
Philip Zozobrado edited a comment on Bug JENKINS-56402
[~kapoorlakshya], unfortunately, {{always}} runs first. That won't work:
* [https://jenkins.io/doc/book/pipeline/syntax/#post]

{quote}The condition blocks are executed in the order shown below.
always, changed, fixed, regression, aborted, failure, success, unstable, unsuccessful, and cleanup.
{quote}

There's also some fall-through waterfalling not documented: {{fixed}} will _also_ run {{success}}, for example.


I've updated my pipeline to:
{code}
        post {
            cleanup {
                cleanWs()
            }
            failure {
                notifySlack([status  : 'FAILURE',
                     pipeline: this] as JenkinsStatus)
            }
            fixed {
                notifySlack([status  : 'FIXED',
                     pipeline: this] as JenkinsStatus)
            }
            unstable {
                notifySlack([status  : 'UNSTABLE',
                     pipeline: this] as JenkinsStatus)
            }
            success {
                notifySlack([status  : 'SUCCESS',
                     pipeline: this] as JenkinsStatus)
            }
        }
{code}

However, I'm still looking for a way to kill the {{fixed}} fall-through waterfall into {{success}} .

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 5, 2019, 5:16:02 PM3/5/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
Hi [~dnusbaum], my use case is similar to [~pzozobrado]'s. I am sending an email notification in my post step ({{always}}) and I am using {{currentBuild.currentResult}} to determine the font color for the build status and the subject line in the email:
{code:java}

def statusColor = colorCodeByStatus(currentBuild.currentResult) // $BUILD_STATUS font color

...

// Returns HEX code based on given build status
def colorCodeByStatus(status) {
  if(status == 'SUCCESS') {
    '#28B463' // Green
    
  } else if(status == 'FAILURE') {
    '#DF0101' // Red

  } else { // Aborted or Unstable
    '#9E9E9E' // Gray
  }
}
{code}

I am not sure if this violates any sort of best practices, but this could be a workaround for such use cases:
{code:java}

post {
  success {
      currentBuild.currentResult = 'SUCCESS'
  }
  unstable {
      currentBuild.currentResult = 'UNSTABLE'
  }
  failure {
      currentBuild.currentResult = 'FAILURE'
  }
  always {
    dir(path: 'report') {
      executePostSteps(JOB_NAME)
    }
  }
} // post
{code}

 I haven't had a chance to test it yet, so please feel free to critique it.

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 6, 2019, 9:34:02 AM3/6/19
to jenkinsc...@googlegroups.com

Lakshya Kapoor Your workaround won't work as Philip Zozobrado pointed out because always runs first, however cleanup has the same semantics as always other than running last, so you might be able to use it for your workaround.

I think that it would be possible to support the use cases you both have mentioned by creating a new read-only variable that would only be set inside of post conditions in Declarative that would represent the current logical build status versus currentBuild.result which is just the literal value of Run.result. That way you would be able to access the current build status without Declarative needing to modify Run.result which is problematic in some cases.

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 6, 2019, 9:47:06 AM3/6/19
to jenkinsc...@googlegroups.com
Devin Nusbaum edited a comment on Bug JENKINS-56402
[~kapoorlakshya] Your workaround won't work as [~pzozobrado] pointed out because {{always}} runs first, however {{cleanup}} has the same semantics as {{always}} other than running last, so you might be able to can probably use it for your workaround as they demonstrated .

I think that it would be possible to support the use cases you both have mentioned by creating a new read-only variable that would only be set inside of post conditions in Declarative that would represent the current logical build status versus {{currentBuild.result}} which is just the literal value of {{Run.result}}. That way you would be able to access the current build status without Declarative needing to modify {{Run.result}} which is problematic in some cases.

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 6, 2019, 9:47:07 AM3/6/19
to jenkinsc...@googlegroups.com
Devin Nusbaum edited a comment on Bug JENKINS-56402
[~kapoorlakshya] Your workaround won't work as [~pzozobrado] pointed out because {{always}} runs first, however {{cleanup}} has the same semantics as {{always}} other than running last, so you can probably use it for your workaround as they demonstrated.

 [~pzozobrado] Fall-through happens for changed, fixed, and regression, (and always, unsuccessful, and cleanup, but those are probably less interesting). The reason is that in Jenkins these conditions are not a first-class result, so Declarative computes them based on the current build status in comparison to the previous build's result, so one of aborted, failure, success, unstable, or notBuilt will always be executed if one of changed, fixed, or regression is executed. More than one of aborted, failure, success, unstable, and notBuilt will not be executed in the same post block.

I think that it would be possible to support the use cases you both have mentioned by creating a new read-only variable that would only be set inside of post conditions in Declarative that would represent the current logical build status versus {{currentBuild.result}} which is just the literal value of {{Run.result}}. That way you would be able to access the current build status without Declarative needing to modify {{Run.result}} which is problematic in some cases.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 6, 2019, 10:47:02 AM3/6/19
to jenkinsc...@googlegroups.com

Test.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 6, 2019, 10:48:02 AM3/6/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor updated an issue
 
Change By: Lakshya Kapoor
Comment: Test.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 6, 2019, 11:12:02 AM3/6/19
to jenkinsc...@googlegroups.com

The condition blocks are executed in the order shown below.

Yea, I had a feeling it would be that way, but wasn't sure. Thanks for pointing it out!

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 6, 2019, 11:15:05 AM3/6/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
@Philip
 {quote}The condition blocks are executed in the order shown below.
{quote}

Yea, I had a feeling it would be that way, but wasn't sure. Thanks for pointing it out!

@Devin - I like your idea for the new read-only variable.

P.S. JIRA is giving me a "Communications Breakdown" error when I @ your usernames.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 6, 2019, 11:15:10 AM3/6/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
@Philip
{quote}The condition blocks are executed in the order shown below.
{quote}
Yea, I had a feeling it would be that way, but wasn't sure. Thanks for pointing it out!

@Devin - I like your idea for the new read-only variable.

P.S. JIRA is giving me a "Communications Breakdown" error when I @ your usernames.
Was getting it since yesterday afternoon, but just figured it out it is related to tagging people.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 6, 2019, 11:17:02 AM3/6/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
@Philip
{quote}The condition blocks are executed in the order shown below.
{quote}
Yea, I had a feeling it would be was that way, but wasn't sure. Thanks for pointing it out! :)

@Devin - I like your idea for the new read-only variable.

P.S. JIRA is giving me a "Communications Breakdown" error when I @ your usernames. Was getting it since yesterday afternoon, but just figured it out it is related to tagging people.

c.amshoff@gmx.de (JIRA)

unread,
Mar 7, 2019, 5:41:02 AM3/7/19
to jenkinsc...@googlegroups.com

We run into this issue after last update of Jenkins core and plugins. It's highly critical because it results in wrong mails/notifications and changed behavior.

Using currentBuild.result was a documented, working way of accessing the build result, also for declarative pipelines. It's not an option to change hundreds of pipelines in various branches and move code from always block to different post condition blocks. This would just duplicate a lot of code, like the call of emailext step.

Moveover, the issue makes some plugins like claim-plugin unusable. This is called by step([$class: 'ClaimPublisher']) in the post section, and internally evaluates the build's status in order to decide whether to show claim functionality (build result is failure or unstalbe) or not; see ClaimPublisher.java:

 

@Override
public void perform(@Nonnull Run<?, ?> build, @Nonnull FilePath workspace, @Nonnull Launcher launcher,
                    @Nonnull TaskListener listener) throws InterruptedException, IOException {        
  Result runResult = build.getResult();
  if (runResult != null && runResult.isWorseThan(Result.SUCCESS)) {
    ...
  }
}

Since the result is always SUCCESS now, claim UI elements are never shown. Same applies to some custom plugins developed here.

Thus, please restore the previous functionality ASAP! After that, you might think about better ways to fix the edge cases or provide new variables...

michelzanini@gmail.com (JIRA)

unread,
Mar 7, 2019, 5:57:02 AM3/7/19
to jenkinsc...@googlegroups.com

Hi Devin Nusbaum,

I used currentBuild.currentResult in a good number of places and was affected by this issue. I think we should revert it or provide an alternative way.
I used it with at least 4 different plugins: Slack, MS Teams, Email Ext and InfluxDB.

For Slack is basically similar to what has being described already:

String slackMessage() {
  "Build *${env.JOB_NAME}* finished with status *${currentBuild.currentResult}*"
}

String slackColor() {
  "${currentBuild.currentResult == 'SUCCESS' ? 'good' : 'danger'}"
}

I don't want to have to repeat the above for each type of result, instead, is easier on the pipeline library to just read the status as above.

For MS teams I have got:

pipeline.office365ConnectorSend message: 'Build completed',
        status: currentBuild.currentResult,
        webhookUrl: msTeamsWebhookUrl,
        color: currentBuild.currentResult == 'SUCCESS' ? '82C441' : 'C81423'

Same use case as Slack.

Another case with Slack and MS Teams is that we use a combination of lock and milestone plugins, so sometimes a build is skipped and the result is NOT_BUILT, so we have this:

if (currentBuild.currentResult == 'NOT_BUILT') {
 //don't send Slack / MS Teams message in this case as this build has being skipped by lock/milestone
}

Now, the tricky cases are Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb).
They need a value on currentBuild.result to function properly.
So for both of them I have to do this before using the plugins:

//to fix issue where mailer needs 'currentBuild.result' which is always null at this point - without this email does not report build result correctly
currentBuild.result = currentBuild.currentResult

step([$class: 'Mailer', recipients: emailList])

And InfluxDB:

//to fix issue where InfluxDbPublisher needs 'currentBuild.result' which is always null at this point - without this build result is not reported to InfluxDB
currentBuild.result = currentBuild.currentResult

step([$class: 'InfluxDbPublisher', target: 'influxdb'])

Both Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb) are a bit old (they don't seem to support Declarative Pipelines directly, and instead we need to use step).

After this bug was introduced I have easy way of "fixing" this two plugins and all of the above cases stopped working for me.

michelzanini@gmail.com (JIRA)

unread,
Mar 7, 2019, 5:58:02 AM3/7/19
to jenkinsc...@googlegroups.com
Michel Zanini edited a comment on Bug JENKINS-56402
Hi [~dnusbaum],

I used _currentBuild.currentResult_ in a good number of places and was affected by this issue. I think we should revert it or provide an alternative way.
I used it with at least 4 different plugins: *Slack, MS Teams, Email Ext and InfluxDB*.


For Slack is basically similar to what has being described already:

{code:java}

String slackMessage() {
  "Build *${env.JOB_NAME}* finished with status *${currentBuild.currentResult}*"
}

String slackColor() {
  "${currentBuild.currentResult == 'SUCCESS' ? 'good' : 'danger'}"
}
{code}


I don't want to have to repeat the above for each type of result, instead, is easier on the pipeline library to just read the status as above.

For MS teams I have got:

{code:java}

pipeline.office365ConnectorSend message: 'Build completed',
        status: currentBuild.currentResult,
        webhookUrl: msTeamsWebhookUrl,
        color: currentBuild.currentResult == 'SUCCESS' ? '82C441' : 'C81423'
{code}


Same use case as Slack.

Another case with Slack and MS Teams is that we use a combination of lock and milestone plugins, so sometimes a build is skipped and the result is NOT_BUILT, so we have this:

{code:java}

if (currentBuild.currentResult == 'NOT_BUILT') {
//don't send Slack / MS Teams message in this case as this build has being skipped by lock/milestone
}
{code}


Now, the tricky cases are Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb).
They need a value on _currentBuild.result_ to function properly.

So for both of them I have to do this before using the plugins:

{code:java}

//to fix issue where mailer needs 'currentBuild.result' which is always null at this point - without this email does not report build result correctly
currentBuild.result = currentBuild.currentResult

step([$class: 'Mailer', recipients: emailList])
{code}

And InfluxDB:

{code:java}

//to fix issue where InfluxDbPublisher needs 'currentBuild.result' which is always null at this point - without this build result is not reported to InfluxDB
currentBuild.result = currentBuild.currentResult

step([$class: 'InfluxDbPublisher', target: 'influxdb'])
{code}


Both Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb) are a bit old (they don't seem to support Declarative Pipelines directly, and instead we need to use step).

After this bug was introduced I don't have an easy way of "fixing" this two plugins and all of the above cases stopped working for me.

c.amshoff@gmx.de (JIRA)

unread,
Mar 7, 2019, 7:22:02 AM3/7/19
to jenkinsc...@googlegroups.com

michelzanini@gmail.com (JIRA)

unread,
Mar 7, 2019, 8:12:03 AM3/7/19
to jenkinsc...@googlegroups.com

Yes Christoph Amshoff, thanks. At the time I did this there was an issue with it, I don't remind what exactly, but yes I can try migrate, but not sure the problem with build result will go away....

peter_carenza@bcbst.com (JIRA)

unread,
Mar 7, 2019, 11:20:04 AM3/7/19
to jenkinsc...@googlegroups.com

I agree with Christoph and Michael in that there's not just one, but several, plugins that break because of this change... and the change is often subtle. For instance, we didn't know about the false SUCCESS reports we were getting by email until we actually took a look at the log and found that the pipeline was actually failing.

Granted, we're a small enough organization that uses just a few distributed pipelines and a standard jenkinsfile, so we were able to add a workaround, but for those like Cristoph who have to deal with hundreds of them, it's needless technical debt. 

steffen.wilke@wibemedia.de (JIRA)

unread,
Mar 7, 2019, 12:21:04 PM3/7/19
to jenkinsc...@googlegroups.com

For us, this issue is equally urgent as for Christoph Amshoff. I agree with Michel Zanini on the approach to "revert it or provide an alternative way." Right now, this change caused developers to be notified with a "Build Completed" Email in our infrastructure, even though the build actually failed.

I just wish there would be something like an LTS release line for these deeply integrated plugins. This would greatly increase their reliability.

steffen.wilke@wibemedia.de (JIRA)

unread,
Mar 7, 2019, 12:22:02 PM3/7/19
to jenkinsc...@googlegroups.com
Steffen Wilke updated an issue
 
Change By: Steffen Wilke
Priority: Major Critical

steffen.wilke@wibemedia.de (JIRA)

unread,
Mar 7, 2019, 12:24:03 PM3/7/19
to jenkinsc...@googlegroups.com
Steffen Wilke updated an issue
Change By: Steffen Wilke
Environment: Jenkins 2.150.3, Pipeline 2.6, Pipeline: Declarative plugin v1.3.5, using a slave build executioner

callum+jenkins@callumpember.com (JIRA)

unread,
Mar 7, 2019, 7:51:10 PM3/7/19
to jenkinsc...@googlegroups.com
Callum Pember commented on Bug JENKINS-56402
 
Re: Declarative Pipeline shows SUCCESS even though job FAILED

+1. We have jobs that rely on this, e.g. compare previous build against current build, set slack message color, etc etc. As it stands, it seems there is no way to determine if the build is failing right now, even with the hudson API?

callum+jenkins@callumpember.com (JIRA)

unread,
Mar 7, 2019, 7:52:03 PM3/7/19
to jenkinsc...@googlegroups.com
Callum Pember edited a comment on Bug JENKINS-56402
+1. We have jobs that rely on this, e.g. compare previous build against current build, set slack message color, etc etc. As it stands, it seems there is no way to determine if the build is failing right now, even with the hudson API? I had to add a function to read the build log :(

jsmith45@sogetthis.com (JIRA)

unread,
Mar 8, 2019, 11:44:03 AM3/8/19
to jenkinsc...@googlegroups.com

I understand that setting currentBuild.status for stage-level post conditions could potentially be problematic.

But for the overall post conditions of the build there seems to be little reason not to set it if the build as a whole is failed. 
This is the point point where people are most likely to use various plugins originally designed for freestyle projects that expect a result to be set. Some of them have been upgraded to treat an unset status value as success, which means that they worked fine in an overall post-build step, prior to the recent change, but don't anymore.

In the alternative, at the very minimum the read only value proposed would help. In practice people would just use it to
initialize currentBuild.result though, in order to make various legacy plugins happy.

andrew.bayer@gmail.com (JIRA)

unread,
Mar 8, 2019, 5:15:02 PM3/8/19
to jenkinsc...@googlegroups.com

I've just merged a potential fix (https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/319) and am cutting 1.3.7-beta-1 now - see https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/ for how you can install the beta. It should be in the update center within an hour or so. We'd appreciate your feedback as to how this change works for you - if it turns out not to solve enough of the use cases, we'll switch to reverting the problematic change completely, but we'd really like to be able to keep it in if we can. Thanks, and we appreciate your patience and are very sorry for the inconvenience this change has caused.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 8, 2019, 8:13:07 PM3/8/19
to jenkinsc...@googlegroups.com
Lakshya Kapoor edited a comment on Bug JENKINS-56402
Thanks, [~abayer] and [~dnusbaum] ! I'll test 1.3.7-beta-1 on Monday and report back.

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 8, 2019, 8:13:07 PM3/8/19
to jenkinsc...@googlegroups.com

Thanks, Andrew Bayer! I'll test 1.3.7-beta-1 on Monday and report back.

c.amshoff@gmx.de (JIRA)

unread,
Mar 10, 2019, 7:53:02 AM3/10/19
to jenkinsc...@googlegroups.com

I've installed 1.3.7-beta-1 version of all four pipeline plugins (Pipeline: Declarative, Pipeline: Declarative Extension Points API, Pipeline: Model API and Pipeline: Stage Tags Metadata) and can confirm that it works! Status in post action is correcct now, mails are sent with proper status and Claims plugin's icon shows up again for unstable or failed builds.

So, thanks for the fix! I really appreciate your efforts, and can imagine it's hard to fix this messy status implementation without breaking any functionality...

royarnon@gmail.com (JIRA)

unread,
Mar 11, 2019, 9:37:02 AM3/11/19
to jenkinsc...@googlegroups.com

Just wanted to remark that the currentBuild.resultIsBetterOrEqualTo / resultIsWorseOrEqualTo also does not work because of the same issue - assuming they use the same currentBuild.currentResult internally.

steffen.wilke@wibemedia.de (JIRA)

unread,
Mar 11, 2019, 12:49:03 PM3/11/19
to jenkinsc...@googlegroups.com

1.3.7-beta-1 also fixed the issue for our infrastructure: Andrew Bayer Devin Nusbaum thank you very much for the fast response and fix!

michelzanini@gmail.com (JIRA)

unread,
Mar 12, 2019, 2:00:05 PM3/12/19
to jenkinsc...@googlegroups.com

1.3.7-beta-1 is a very good improvement. Not just it works like before, it also works better.

Now I won't need to do this anymore:

currentBuild.result = currentBuild.currentResult

To make it easy for everyone to see differences between the versions. I will post the result of executing the pipeline that is on the description of this issue below, on all different versions, so people can easily spot the differences.

1.3.4.1 and below:

Init result: null
Init currentResult: SUCCESS

Post-Init result: null
Post-Init currentResult: SUCCESS

During Build result: null
During Build currentResult: SUCCESS

Post-Build result: FAILURE
Post-Build currentResult: FAILURE

Pipeline result: FAILURE
Pipeline currentResult: FAILURE

Note: problem with 1.3.6 is that it shows 'Post-Init result: null' where at that point it could be SUCCESS

1.3.6:

Init result: null
Init currentResult: SUCCESS

Post-Init result: null
Post-Init currentResult: SUCCESS

During Build result: null
During Build currentResult: SUCCESS

Post-Build result: null
Post-Build currentResult: SUCCESS

Pipeline result: null
Pipeline currentResult: SUCCESS

Note: This is the worse version because result is always 'null' and currentResult always 'SUCCESS'

1.3.7-beta-1:

Init result: null
Init currentResult: SUCCESS

Post-Init result: SUCCESS
Post-Init currentResult: SUCCESS

During Build result: null
During Build currentResult: SUCCESS

Post-Build result: FAILURE
Post-Build currentResult: FAILURE

Pipeline result: FAILURE
Pipeline currentResult: FAILURE

Note: this is the best version because both property are always correct on post blocks

kapoorlakshya@gmail.com (JIRA)

unread,
Mar 13, 2019, 7:28:02 PM3/13/19
to jenkinsc...@googlegroups.com

I am also glad to confirm that currentBuild.currentResult in v1.3.7-beta1 works as it did in v1.3.4.1. Thanks again!

kostrzewa@9livesdata.com (JIRA)

unread,
Mar 19, 2019, 5:59:04 AM3/19/19
to jenkinsc...@googlegroups.com

Does anyone know when 1.3.7 will be released?

andrew.bayer@gmail.com (JIRA)

unread,
Mar 19, 2019, 8:26:02 AM3/19/19
to jenkinsc...@googlegroups.com

Hopefully this week - we’re trying to solve a bug in the original fix that created this problem in the first place, but if we aren’t able to nail that down in the next couple days, I’ll release 1.3.7 as it is now.

andrew.bayer@gmail.com (JIRA)

unread,
Mar 20, 2019, 11:28:07 AM3/20/19
to jenkinsc...@googlegroups.com
Andrew Bayer resolved as Fixed
 

Released just now as 1.3.7 - let us know if you see any problems and we'll get on them ASAP!
Change By: Andrew Bayer
Status: Open Resolved
Resolution: Fixed

felix.retter@qtronic.de (JIRA)

unread,
Mar 22, 2019, 3:59:03 AM3/22/19
to jenkinsc...@googlegroups.com
Felix Retter commented on Bug JENKINS-56402
 
Re: Declarative Pipeline shows SUCCESS even though job FAILED

Thanks Andrew. 1.3.7 looks very promising

dnusbaum@cloudbees.com (JIRA)

unread,
Mar 26, 2019, 2:25:05 PM3/26/19
to jenkinsc...@googlegroups.com
Devin Nusbaum updated an issue
 
Change By: Devin Nusbaum
Released As: pipeline-model-definition 1.3.7

bitwiseman@gmail.com (JIRA)

unread,
Oct 22, 2019, 11:25:05 PM10/22/19
to jenkinsc...@googlegroups.com
Liam Newman closed an issue as Fixed
 

Bulk closing resolved issues.

Change By: Liam Newman
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

artourklevin@gmail.com (JIRA)

unread,
Dec 30, 2019, 4:58:10 AM12/30/19
to jenkinsc...@googlegroups.com
Artour Klevin reopened an issue
 

With current version 1.5.0 of Pipeline: Declarative Plugin.
I get the same issue.
 
Change By: Artour Klevin
Resolution: Fixed
Status: Closed Reopened

dnusbaum@cloudbees.com (JIRA)

unread,
Jan 2, 2020, 11:07:11 AM1/2/20
to jenkinsc...@googlegroups.com
Devin Nusbaum commented on Bug JENKINS-56402
 
Re: Declarative Pipeline shows SUCCESS even though job FAILED

Artour Klevin If you reopen an old issue, please include a full reproduction case of the issue you are seeing, and describe the actual and expected behavior. In this case, since the issue has been fixed since March, it would be better to open a new ticket to track whatever issue you are seeing separately, so I am going to re-close this issue.

dnusbaum@cloudbees.com (JIRA)

unread,
Jan 2, 2020, 11:07:12 AM1/2/20
to jenkinsc...@googlegroups.com
Devin Nusbaum closed an issue as Fixed
 
Change By: Devin Nusbaum
Status: Reopened Closed
Resolution: Fixed

drdamour@gmail.com (JIRA)

unread,
Jan 2, 2020, 11:30:04 AM1/2/20
to jenkinsc...@googlegroups.com
chirs damour commented on Bug JENKINS-56402
 
Re: Declarative Pipeline shows SUCCESS even though job FAILED

For people who reported watched this issue its nice that the issue is reopened because it gets it on our radar. Forcing A new issue is a disservice to your hard core issue reporting users who wouldnt get notified

But totally should have recreate steps

dnusbaum@cloudbees.com (JIRA)

unread,
Jan 2, 2020, 11:53:03 AM1/2/20
to jenkinsc...@googlegroups.com

chirs damour By all means, if you open a new issue that is related to an old issue, please comment on the old issue mentioning that you saw something similar, include a link to the new issue, and add a "relates to" issue link in Jira to the other issue. I think it is ok to reopen an issue if you do so very soon after it was originally resolved/closed, since the context is still the same, but given this issue was originally closed in March 2019, I think we need to reevaluate any related issue from scratch. For example, is the fix completely broken (hopefully not, we added some regression tests with the fix), is this a slightly different use case, does it only break when using matrix or parallel, etc.

artourklevin@gmail.com (JIRA)

unread,
Jan 2, 2020, 3:25:03 PM1/2/20
to jenkinsc...@googlegroups.com

Sorry for just re-opening it without adding more information.
It looked very similar to my problem, but after spending another day on it, I have no issues.

I just set the curentBuild.result = 'FAILURE' in the catch when my step fails in the pipeline.
Then everything works as I would like it to.

Thanks for keeping the plugin alive! 
Reply all
Reply to author
Forward
0 new messages