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

    XMLWordPrintable

Details

    Description

      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

      Attachments

        Activity

          j_martin Jean-Martin Archer created issue -
          j_martin Jean-Martin Archer made changes -
          Field Original Value New Value
          Summary sing a milestone before an input will abort older build if there is a failure while the older build wait for a user input Using a milestone before an input will abort older build if there is a failure while the older build wait for a user input
          j_martin Jean-Martin Archer made changes -
          Description h2. Problem
          When:

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



          h2. Duplication Steps
          # Create a job with the following code:
          \{code:title=|language=none|collapse=false}node \{
           milestone label: 'test1', ordinal: 1
           input 'test'
           sh 'exit 1'
          }
          \{code}
          # Trigger two builds.
          # Approve the newest job (#2) to continue.

          h2. Current behavior
          The newer job (#2) will fail, the older job (#1) will be aborted and display \{\{Superseded by <jobname>#<build_num>}}

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

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

          \{code:title=|language=none|collapse=false}node \{
           input 'test'
           sh 'exit 1'
           milestone label: 'test1', ordinal: 1
          }
          \{code}

          Might be tangeantially related to JENKINS-41604
          h2. Problem

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

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

          h2. 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.
          h2. Expected behavior

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

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

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

          Might be tangeantially related to JENKINS-41604
          j_martin Jean-Martin Archer made changes -
          Description h2. Problem

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

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

          h2. 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.
          h2. Expected behavior

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

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

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

          Might be tangeantially related to JENKINS-41604
          h2. Problem

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

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

          h2. 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.
          h2. Expected behavior

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

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

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

          Might be tangeantially related to JENKINS-41604

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

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

          tkleiber Torsten Kleiber added a comment - Same happens, when user aborts the input or the whole build.
          tkleiber Torsten Kleiber made changes -
          Priority Minor [ 4 ] Critical [ 2 ]
          tkleiber 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.

          tkleiber 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
          tkleiber 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

          People

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

            Dates

              Created:
              Updated: