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 -

          This should be fairly trivial to add. Unfortunately arbitrary tools may use that exit code to indicate failure, just like exist code 1, or 5, or anything non-zero, and starting to mark builds as unstable (and continue execution!) is a very backwards incompatible change, so won't be added.

          The only compatible solution I could think of would be an 'Advanced' option to designate specific exit codes for a shell script/batch file builder to indicate 'Unstable'.

          Daniel Beck added a comment - This should be fairly trivial to add. Unfortunately arbitrary tools may use that exit code to indicate failure, just like exist code 1, or 5, or anything non-zero, and starting to mark builds as unstable (and continue execution!) is a very backwards incompatible change, so won't be added. The only compatible solution I could think of would be an 'Advanced' option to designate specific exit codes for a shell script/batch file builder to indicate 'Unstable'.

          Craig Ringer added a comment -

          Indeed - I'd assumed that'd have to be the case, which means adding new UI in an unfamiliar declarative UI generator. Fun. I'll have a look and see what's involved.

          Craig Ringer added a comment - Indeed - I'd assumed that'd have to be the case, which means adding new UI in an unfamiliar declarative UI generator. Fun. I'll have a look and see what's involved.

          Craig Ringer added a comment -

          ./core/src/main/java/hudson/tasks/CommandInterpreter.java already has an extension point for this, join(Proc p), but it's incomplete. See JENKINS-23896 .

          Craig Ringer added a comment - ./core/src/main/java/hudson/tasks/CommandInterpreter.java already has an extension point for this, join(Proc p), but it's incomplete. See JENKINS-23896 .

          Craig Ringer added a comment -

          Depends on the fix in JENKINS-23896 for access to the Build object

          Craig Ringer added a comment - Depends on the fix in JENKINS-23896 for access to the Build object

          Craig Ringer added a comment -

          Craig Ringer added a comment - Created pull https://github.com/jenkinsci/jenkins/pull/1325 for this.

          Craig Ringer added a comment -

          Requires the fix in JENKINS-23896 . Merge that first.

          Craig Ringer added a comment - Requires the fix in JENKINS-23896 . Merge that first.

          Craig Ringer added a comment -

          With this patch, instead you just write:

          make
          if ! make check; then 
            exit 2
          fi
          

          or if you like to document your constants and you set the unstable result to 2:

          JENKINS_RETURN_UNSTABLE=2
          make
          if ! make check; then 
            exit $JENKINS_RETURN_UNSTABLE
          fi
          

          Craig Ringer added a comment - With this patch, instead you just write: make if ! make check; then exit 2 fi or if you like to document your constants and you set the unstable result to 2: JENKINS_RETURN_UNSTABLE=2 make if ! make check; then exit $JENKINS_RETURN_UNSTABLE fi

          Craig Ringer added a comment -

          I've updated the pull request with:

          • support for BatchFile too
          • Unit tests

          and think it's ready to go.

          Craig Ringer added a comment - I've updated the pull request with: support for BatchFile too Unit tests and think it's ready to go.

          AnneTheAgile added a comment - - edited

          ringerc, did you ever get feedback on your patch? I don't know how patches normally get added to Jenkins?
          I would love this fix too.

          p.s. Note, the linked "Duplicate" ticket was closed in favor of this one.

          AnneTheAgile added a comment - - edited ringerc , did you ever get feedback on your patch? I don't know how patches normally get added to Jenkins? I would love this fix too. p.s. Note, the linked "Duplicate" ticket was closed in favor of this one.

          Daniel Beck added a comment -

          Daniel Beck added a comment - annetheagile See https://github.com/jenkinsci/jenkins/pull/1325#issuecomment-107914540

          Code changed in jenkins
          User: Craig Ringer
          Path:
          core/src/main/java/hudson/tasks/Shell.java
          core/src/main/resources/hudson/tasks/Shell/config.groovy
          test/src/test/java/hudson/tasks/ShellTest.java
          http://jenkins-ci.org/commit/jenkins/e773eb44621ded75e66e4d4b3aa6f7a48bebcb49
          Log:
          JENKINS-23786: Allow Shell jobs to set a return code for unstable

          Currently a shell job has to make a HTTP call back to Jenkins to set
          its build result as unstable. This is slow, requires the slave to
          have access to the master's HTTP interface, and is fiddly. The
          alternative, the TextFinder plugin, is no better.

          Instead, allow a job to set the build result to unstable with a
          return value.

          Adds the Advanced parameter "unstableReturn" which, if non-zero,
          is the code the script must return to set the build as unstable.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Craig Ringer Path: core/src/main/java/hudson/tasks/Shell.java core/src/main/resources/hudson/tasks/Shell/config.groovy test/src/test/java/hudson/tasks/ShellTest.java http://jenkins-ci.org/commit/jenkins/e773eb44621ded75e66e4d4b3aa6f7a48bebcb49 Log: JENKINS-23786 : Allow Shell jobs to set a return code for unstable Currently a shell job has to make a HTTP call back to Jenkins to set its build result as unstable. This is slow, requires the slave to have access to the master's HTTP interface, and is fiddly. The alternative, the TextFinder plugin, is no better. Instead, allow a job to set the build result to unstable with a return value. Adds the Advanced parameter "unstableReturn" which, if non-zero, is the code the script must return to set the build as unstable.

          Code changed in jenkins
          User: Craig Ringer
          Path:
          core/src/main/java/hudson/tasks/BatchFile.java
          core/src/main/resources/hudson/tasks/BatchFile/config.jelly
          core/src/main/resources/hudson/tasks/BatchFile/config.properties
          test/src/test/java/hudson/tasks/BatchFileTest.java
          http://jenkins-ci.org/commit/jenkins/4b067fdf15fc1568ce27a921e41047201047507b
          Log:
          JENKINS-23786: Allow batch files to set an exit code for unstable builds

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Craig Ringer Path: core/src/main/java/hudson/tasks/BatchFile.java core/src/main/resources/hudson/tasks/BatchFile/config.jelly core/src/main/resources/hudson/tasks/BatchFile/config.properties test/src/test/java/hudson/tasks/BatchFileTest.java http://jenkins-ci.org/commit/jenkins/4b067fdf15fc1568ce27a921e41047201047507b Log: JENKINS-23786 : Allow batch files to set an exit code for unstable builds

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/hudson/tasks/BatchFile.java
          core/src/main/java/hudson/tasks/CommandInterpreter.java
          core/src/main/java/hudson/tasks/Shell.java
          core/src/main/resources/hudson/tasks/BatchFile/config.jelly
          core/src/main/resources/hudson/tasks/BatchFile/help-unstableReturn.html
          core/src/main/resources/hudson/tasks/Messages.properties
          core/src/main/resources/hudson/tasks/Shell/config.groovy
          core/src/main/resources/hudson/tasks/Shell/config.properties
          core/src/main/resources/hudson/tasks/Shell/help-unstableReturn.html
          test/src/test/java/hudson/tasks/BatchFileTest.java
          test/src/test/java/hudson/tasks/ShellTest.java
          http://jenkins-ci.org/commit/jenkins/720b75f096e573b102323b529ec952e2106d4a57
          Log:
          Merge pull request #2563 from stochmial/shell-setunstable-rebased

          JENKINS-23786 Permit the Shell plugin to set a build result as unstable via a return code

          Compare: https://github.com/jenkinsci/jenkins/compare/74c534207ca0...720b75f096e5

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/hudson/tasks/BatchFile.java core/src/main/java/hudson/tasks/CommandInterpreter.java core/src/main/java/hudson/tasks/Shell.java core/src/main/resources/hudson/tasks/BatchFile/config.jelly core/src/main/resources/hudson/tasks/BatchFile/help-unstableReturn.html core/src/main/resources/hudson/tasks/Messages.properties core/src/main/resources/hudson/tasks/Shell/config.groovy core/src/main/resources/hudson/tasks/Shell/config.properties core/src/main/resources/hudson/tasks/Shell/help-unstableReturn.html test/src/test/java/hudson/tasks/BatchFileTest.java test/src/test/java/hudson/tasks/ShellTest.java http://jenkins-ci.org/commit/jenkins/720b75f096e573b102323b529ec952e2106d4a57 Log: Merge pull request #2563 from stochmial/shell-setunstable-rebased JENKINS-23786 Permit the Shell plugin to set a build result as unstable via a return code Compare: https://github.com/jenkinsci/jenkins/compare/74c534207ca0...720b75f096e5

          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: