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

create a step to abort the build with a NOT_BUILT status

    • Pipeline - April 2018

      The error step results in a workflow with a "FAILURE" state.

      It is desirable to be able to end a workflow early from within the workflow itself but not have the workflow in an error state (which would imply a user needs to take a look at why it failed and perform so work).

      e.g.
      say I do not want to deploy any code to production on a Friday afternoon

      A step that stops the workflow on a Friday afternoon should not result in the build being failed but in one that it has been intentionally cut short.

          [JENKINS-27092] create a step to abort the build with a NOT_BUILT status

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/main/java/hudson/plugins/git/GitStatus.java
          src/test/java/hudson/plugins/git/GitStatusTest.java
          http://jenkins-ci.org/commit/git-plugin/2dfd86d27a7cd4089349fd012d7d70a5e827ed81
          Log:
          Test JENKINS-30178 using GitStatus.toString

          Asserts that job parameter default values are available when a job
          is started by a notifyCommit. If the notifyCommit includes a sha1
          parameter, then the changes for JENKINS-27092 fail to assign parameters
          their default values.

          Modifying the GitStatus object to be more easily tested was simpler
          than using a TestExtension. Should eventually replace the testing
          misuse of the GitStatus.toString() method with a TestExtension of
          GitStatus.Listener.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/hudson/plugins/git/GitStatus.java src/test/java/hudson/plugins/git/GitStatusTest.java http://jenkins-ci.org/commit/git-plugin/2dfd86d27a7cd4089349fd012d7d70a5e827ed81 Log: Test JENKINS-30178 using GitStatus.toString Asserts that job parameter default values are available when a job is started by a notifyCommit. If the notifyCommit includes a sha1 parameter, then the changes for JENKINS-27092 fail to assign parameters their default values. Modifying the GitStatus object to be more easily tested was simpler than using a TestExtension. Should eventually replace the testing misuse of the GitStatus.toString() method with a TestExtension of GitStatus.Listener.

          Jesse Glick added a comment -

          Would be useful in conjunction with JENKINS-30412, to skip builds with uninteresting changes.

          Jesse Glick added a comment - Would be useful in conjunction with JENKINS-30412 , to skip builds with uninteresting changes.

          Jesse Glick added a comment -

          Probably need to fix JENKINS-34464 first.

          Jesse Glick added a comment - Probably need to fix JENKINS-34464 first.

          Jesse Glick added a comment -

          Has also been suggested that SUCCESS would be a useful status, if for example a build should not continue to deployment, though NOT_BUILT is the conventional choice here.

          Jesse Glick added a comment - Has also been suggested that SUCCESS would be a useful status, if for example a build should not continue to deployment, though NOT_BUILT is the conventional choice here.

          Nick Jones added a comment - - edited

          My use case involves wanting to skip CI builds for certain changes (e.g., triggered by a "[ci skip]"-containing commit message, a la AppVeyor, etc.), but in a multbranch pipeline job where status checks get posted back automatically to GitHub, using an error step to do this results in a failed status check, and thus an unmergeable PR. An successful-looking exit would be ideal here.

          For what it's worth, even a NOT_BUILT result causes a failed (or unsuccessful) status check back to GitHub, so without changes to that plugin, I'd really be wanting a way to abort the build early with a true SUCCESS result.

          What I've done for now is to add a when block on every stage, checking an environment variable I'm setting when the build should be skipped. Not DRY, but it works.

          Nick Jones added a comment - - edited My use case involves wanting to skip CI builds for certain changes (e.g., triggered by a " [ci skip] "-containing commit message, a la AppVeyor, etc.), but in a multbranch pipeline job where status checks get posted back automatically to GitHub, using an error step to do this results in a failed status check, and thus an unmergeable PR. An successful-looking exit would be ideal here. For what it's worth, even a NOT_BUILT result causes a failed (or unsuccessful) status check back to GitHub, so without changes to that plugin, I'd really be wanting a way to abort the build early with a true SUCCESS result. What I've done for now is to add a when block on every stage, checking an environment variable I'm setting when the build should be skipped. Not DRY, but it works.

          Baptiste Mathus added a comment - - edited

          I am using a git log check on the content in a Declarative pipeline, already in a script block, to avoid releasing if the current commit is already a release...

          steps {
                          // The release is going to push a new commit, which will trigger again a build...
                          // So to avoid an infinite release loop :P
                          deleteDir()
                          checkout scm
                          sh 'git log --format=%s -1'
                          script {
                              result = sh (script: "git log --format=%s -1 | grep --fixed-string '[maven-release-plugin] prepare'", returnStatus: true)
                              println "WAT: $result"
                              if (result == 0) {
                                  echo "Skipping the release as the current commit is already a release"
                                  return // only gets out from the script block
                              }
                          }
                          // let's start the release dance
          

          I don't see an easy way for this apart from putting everything below in the script block :-\.
          Or alternatively indeed, like Nick suggests, I could set a env var, then due the actual release in a followup stage. But I would have like to avoid that, also because it will render visually a "weird" "pre-release check" stage just for this...

          Baptiste Mathus added a comment - - edited I am using a git log check on the content in a Declarative pipeline, already in a script block, to avoid releasing if the current commit is already a release... steps { // The release is going to push a new commit, which will trigger again a build... // So to avoid an infinite release loop :P deleteDir() checkout scm sh 'git log --format=%s -1' script { result = sh (script: "git log --format=%s -1 | grep --fixed-string '[maven-release-plugin] prepare' " , returnStatus: true ) println "WAT: $result" if (result == 0) { echo "Skipping the release as the current commit is already a release" return // only gets out from the script block } } // let's start the release dance I don't see an easy way for this apart from putting everything below in the script block :-\. Or alternatively indeed, like Nick suggests, I could set a env var, then due the actual release in a followup stage. But I would have like to avoid that, also because it will render visually a "weird" "pre-release check" stage just for this...

          James Dumay added a comment -

          This use case (aborted) and other statuses will be covered in JENKINS-45579.

          James Dumay added a comment - This use case (aborted) and other statuses will be covered in JENKINS-45579 .

          Jesse Glick added a comment -

          This is not a duplicate. The original request was for a way to abort the build: stopping execution by unwinding the call stack. JENKINS-45579 is about marking some status in the stage for visualization purposes and then continuing the build.

          Jesse Glick added a comment - This is not a duplicate. The original request was for a way to abort the build: stopping execution by unwinding the call stack.  JENKINS-45579 is about marking some status in the stage for visualization purposes and then continuing the build.

          Jesse Glick added a comment -

          There is also a use case for passing UNSTABLE: if you have some test failures in one parallel branch and are using failFast, you should be able to interrupt the build now. (Of course this could also be handled directly in the junit step.) Making that look pretty would I think also require replacing ParallelStep.FailFastException with FlowInterruptedException so that the other branches are shown as ABORTED rather than FAILED in Blue Ocean.

          Jesse Glick added a comment - There is also a use case for passing UNSTABLE : if you have some test failures in one parallel branch and are using failFast , you should be able to interrupt the build now. (Of course this could also be handled directly in the junit step.) Making that look pretty would I think also require replacing ParallelStep.FailFastException with FlowInterruptedException so that the other branches are shown as ABORTED rather than FAILED in Blue Ocean.

          Jesse Glick added a comment -

          For example, the buildPlugin library function could benefit from throwing up UNSTABLE.

          There are some interactions here with JENKINS-39203 and JENKINS-49073.

          Jesse Glick added a comment - For example, the buildPlugin library function could benefit from throwing up UNSTABLE . There are some interactions here with JENKINS-39203 and JENKINS-49073 .

            Unassigned Unassigned
            teilo James Nord
            Votes:
            24 Vote for this issue
            Watchers:
            34 Start watching this issue

              Created:
              Updated: