Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-23786

Permit "Execute shell" jobs to return 2 for "unstable"

      Currently, users of "Execute shell" builds must fetch the jenkins-cli jar and execute it in order to mark a build as unstable. For example:

      set -e
      wget ${JENKINS_URL}jnlpJars/jenkins-cli.jar
      make
      if ! make check; then 
        java -jar jenkins-cli.jar set-build-result unstable && exit 0
        exit 1
      fi
      

      will flag as unstable and exit.

      That works, but it's a right pain. The alternative is text-finder plugin string matching, which is arguably worse.

      What'd be ideal is to let the return code 2 mean "unstable" to Jenkins. So one could just replace the above with:

      set -e
      make
      make check || exit 2
      

      I'll see what's involved in adding this, but wanted to put the idea out.

          [JENKINS-23786] Permit "Execute shell" jobs to return 2 for "unstable"

          Daniel Beck added a comment -

          Fixed towards 2.26

          Daniel Beck added a comment - Fixed towards 2.26

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - The fix also includes https://github.com/jenkinsci/jenkins/pull/2563/commits/359548efa074f9ed3537552f5f9f2b51faf33e25

          Martin Jost added a comment -

          So what is now the behaviour ?
          From what I understand from https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/tasks/Shell/help-unstableReturn.html:

          • 0: pass (green)
            "The value 0 is ignored and does not make the build unstable to keep the default behaviour consistent."
          • 1: red (fail) ? Or can this also be used for "unstable" ?
          • a configurable value (!= 0) meaning "unstable"
          • What about other exit values ? Will they make the job red ?

          Is it possible to switch the behaviour off (to old behaviour (0:"pass"; all else "fail") to ease transition to the version containing this ?

          Martin Jost added a comment - So what is now the behaviour ? From what I understand from https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/tasks/Shell/help-unstableReturn.html: 0: pass (green) "The value 0 is ignored and does not make the build unstable to keep the default behaviour consistent." 1: red (fail) ? Or can this also be used for "unstable" ? a configurable value (!= 0) meaning "unstable" What about other exit values ? Will they make the job red ? Is it possible to switch the behaviour off (to old behaviour (0:"pass"; all else "fail") to ease transition to the version containing this ?

          Daniel Beck added a comment -

          Is it possible to switch the behaviour off (to old behaviour (0:"pass"; all else "fail") to ease transition to the version containing this ?

          Quoting the help text, emphasis mine:

          If set, the shell exit code that will be interpreted as an unstable build result.

          Daniel Beck added a comment - Is it possible to switch the behaviour off (to old behaviour (0:"pass"; all else "fail") to ease transition to the version containing this ? Quoting the help text, emphasis mine: If set , the shell exit code that will be interpreted as an unstable build result.

          It was pretty easy to change status with touch file and make conditional status change on file.

          If jenkins interprets exit code 2 specially then it crazy regression, already existing jobs may use unstable for deployment, while failed shell script shouldn't provide the way to trigger build.
          http://tldp.org/LDP/abs/html/exitcodes.html#EXITCODESREF

          Kanstantsin Shautsou added a comment - It was pretty easy to change status with touch file and make conditional status change on file. If jenkins interprets exit code 2 specially then it crazy regression, already existing jobs may use unstable for deployment, while failed shell script shouldn't provide the way to trigger build. http://tldp.org/LDP/abs/html/exitcodes.html#EXITCODESREF

          Huh, found that it configurable, hope it disabled by default.

          Kanstantsin Shautsou added a comment - Huh, found that it configurable, hope it disabled by default.

          Jakub Bochenski added a comment - - edited

          oleg_nenashev danielbeck ringerc can you take a look at JENKINS-47606? I run into problems when trying to use this in a Maven project

          Jakub Bochenski added a comment - - edited oleg_nenashev danielbeck ringerc can you take a look at  JENKINS-47606 ? I run into problems when trying to use this in a Maven project

          Alexej Ismailov added a comment - - edited

          I'm sorry if this is a stupid question, but how do I use this? How to configure jenkins to interpret exit code 2 as unstable?
          If I do this inside a step: 

          sh """exit 2"""

          I get same behaviour as if I would exit with 1:

          11:27:13 Catching error for later recovery: hudson.AbortException: script returned exit code 2
          ...
          [Pipeline] End of PipelineERROR: script returned exit code 2
          Finished: FAILURE
          

          Alexej Ismailov added a comment - - edited I'm sorry if this is a stupid question, but how do I use this? How to configure jenkins to interpret exit code 2 as unstable? If I do this inside a step:  sh """exit 2""" I get same behaviour as if I would exit with 1: 11:27:13 Catching error for later recovery: hudson.AbortException: script returned exit code 2 ... [Pipeline] End of PipelineERROR: script returned exit code 2 Finished: FAILURE

          fatcash all of the above examples, being from 2016, were probably using the "classic" interface which has a field in the UI. In pipeline code, you want to use the "returnStatus" flag when calling sh - see https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#sh-shell-script - unfortunately you cannot use "returnStdout" at the same time; see JENKINS-44930.

          Aaron D. Marasco added a comment - fatcash all of the above examples, being from 2016, were probably using the "classic" interface which has a field in the UI. In pipeline code, you want to use the "returnStatus" flag when calling sh - see https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#sh-shell-script - unfortunately you cannot use "returnStdout" at the same time; see JENKINS-44930 .

          Rares Vernica added a comment -

          See this screenshot on how you can set it. Notice the Exit code to set build unstable field.

          Rares Vernica added a comment - See this screenshot on how you can set it. Notice the Exit code to set build unstable field.

            Unassigned Unassigned
            ringerc Craig Ringer
            Votes:
            11 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated:
              Resolved: