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

create a step to abort the build with a NOT_BUILT status

    XMLWordPrintable

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

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

              People

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

                Dates

                • Created:
                  Updated: