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
          tkleiber Torsten Kleiber made changes -
          Priority Minor [ 4 ] Critical [ 2 ]

          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: