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

Using a milestone before an input will abort older build if there is a failure while the older build wait for a user input

      Problem

      When:

      1. using a milestone before an input,
      2. and one (or more) of the build is waiting for user input,
      3. and a failure in another build happens,
      4. the builds waiting for input will abort older jobs.

      Duplication Steps

      1. Create a job with the following code:
        node {
         milestone label: 'test1', ordinal: 1
         input 'test'
         sh 'exit 1'
        }
        
      2. Trigger two builds.
      3. Approve the newest job (#2) to continue.

      Current behavior

      The newer job (#2) will fail, the older job (#1) will be aborted and display Superseded by <jobname>#<build_num> which is pretty confusing.

      Expected behavior

      The newer job (#2) will fail, while the older job (#1) will wait for confirmation.

      Workaround

      Removing all milestone before the input seems to solve the issue.

      node {
       input 'test'
       sh 'exit 1'
       milestone label: 'test1', ordinal: 1
      }
      

      Might be tangeantially related to JENKINS-41604

          [JENKINS-49447] Using a milestone before an input will abort older build if there is a failure while the older build wait for a user input

          The mentioned workaround unfortunatly means running in another bug: https://issues.jenkins-ci.org/browse/JENKINS-46097

          Torsten Kleiber added a comment - The mentioned workaround unfortunatly means running in another bug: https://issues.jenkins-ci.org/browse/JENKINS-46097

          Same happens, when user aborts the input or the whole build.

          Torsten Kleiber added a comment - Same happens, when user aborts the input or the whole build.

          Torsten Kleiber added a comment - - edited

          Changed to critically as waiting jobs for deployment are cancelled and in combination with buildDiscarder are removed after this.

          Torsten Kleiber added a comment - - edited Changed to critically as waiting jobs for deployment are cancelled and in combination with buildDiscarder are removed after this.

          Here an example of a declarative Pipeline, where 2 input exists and therefore the workaround does not work:

          pipeline {
              agent any
              stages {
                  stage ("Ask 1") {
                      steps {
                          input message: 'Ask 1'
                          milestone ordinal: 1
                          sh '''
          echo $BUILD_NUMBER
          if [ `echo "${BUILD_NUMBER} % 3" | bc` -eq 0 ]
          then
            exit 1
          fi'''
                      }
                  }
                  stage ("Ask 2") {
                      steps {
                          input message: 'Ask 2'
                          milestone ordinal: 2
                      }
                  }
              }
          }
          

          test case 1 - breaking job kills wainting jobs before:

          • start build 1, answer input "Ask 1" with proceed
          • start build 2, answer input "Ask 1" with proceed
          • start build 3, answer input "Ask 1" with proceed
          • > build with build number, which can divided by 3 breaks by default and cancels all waiting job before

          test case 2 - cancel job kills wainting jobs before:

          • start build 1, answer input "Ask 1" with proceed
          • start build 2, answer input "Ask 1" with proceed, answer input "Ask 2" with cancel or cancel the build via the executor cancel button
          • > canceled build cancels all waiting job before

          Torsten Kleiber added a comment - Here an example of a declarative Pipeline, where 2 input exists and therefore the workaround does not work: pipeline { agent any stages { stage ( "Ask 1" ) { steps { input message: 'Ask 1' milestone ordinal: 1 sh ''' echo $BUILD_NUMBER if [ `echo "${BUILD_NUMBER} % 3" | bc` -eq 0 ] then exit 1 fi''' } } stage ( "Ask 2" ) { steps { input message: 'Ask 2' milestone ordinal: 2 } } } } test case 1 - breaking job kills wainting jobs before: start build 1, answer input "Ask 1" with proceed start build 2, answer input "Ask 1" with proceed start build 3, answer input "Ask 1" with proceed > build with build number, which can divided by 3 breaks by default and cancels all waiting job before test case 2 - cancel job kills wainting jobs before: start build 1, answer input "Ask 1" with proceed start build 2, answer input "Ask 1" with proceed, answer input "Ask 2" with cancel or cancel the build via the executor cancel button > canceled build cancels all waiting job before

            amuniz Antonio Muñiz
            j_martin Jean-Martin Archer
            Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: