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

create a step to abort the build with a NOT_BUILT status

    Details

    • Sprint:
      Pipeline - April 2018
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            medianick 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.

            Show
            medianick 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.
            Hide
            batmat 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...

            Show
            batmat 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...
            Hide
            jamesdumay James Dumay added a comment -

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

            Show
            jamesdumay James Dumay added a comment - This use case (aborted) and other statuses will be covered in JENKINS-45579 .
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            jglick 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.

            Show
            jglick 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.

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                teilo James Nord
              • Votes:
                17 Vote for this issue
                Watchers:
                30 Start watching this issue

                Dates

                • Created:
                  Updated: