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

Milestone aborting old builds before passing next milestone

      I may be misunderstanding how to use the milestone, sorry in advance if I am.

      I have a simple pipeline configured as follows:

       

      node('some-node') {
          stage('First') {
              milestone 1
              input(id: 'input', message: 'Deploy?')
          }
          stage('Second') {
              milestone 2
          }
          
      }
      

      If I have builds 1 and 2 sitting at the input step, and I "reject" build #2 so that it does not proceed any further, build #1 is still automatically aborted. This does not make sense to me, because build #2 has not reached "milestone 2". Please advise.

          [JENKINS-60773] Milestone aborting old builds before passing next milestone

          Kai Kunstmann added a comment -

          This Issue should better be titled: "Cancelling a build should not abort older builds in sight of the same milestone".

          I'm having the same problem as the reporting user.

          I have setup a build-pipeline that waits for user approvals before deploying my application to my QA, STAGING and PRODUCTION environments, respectively. The situation is this:

          There are multiple builds waiting for an approval to deploy to STAGING, so all of them are currently in sight of the same previous milestone (e.g. "deployed to QA"). I abort the newest build, because it didn't pass quality requirements on QA, and should never be deployed to STAGING, but I wish for older builds at the same input-step to continue waiting for approval to deploy to STAGING. The bad build gets cancelled as expected, but the milestone plugin subsequently performs some clean-up including aborting all other builds in sight of the same milestone (namely "deployed to QA"). This is not the expected behavior, because the just cancelled build did not progress to the next milestone in order to be allowed to abort its siblings.

           

          I believe, this behaviour is due to this: https://github.com/jenkinsci/pipeline-milestone-step-plugin/blob/ab24d126caaad2c507ec0d26b7cb87d314e1f296/src/main/java/org/jenkinsci/plugins/pipeline/milestone/MilestoneStepExecution.java#L189

          Which is only ever executed from here: https://github.com/jenkinsci/pipeline-milestone-step-plugin/blob/ab24d126caaad2c507ec0d26b7cb87d314e1f296/src/main/java/org/jenkinsci/plugins/pipeline/milestone/MilestoneStepExecution.java#L330

           

          Kai Kunstmann added a comment - This Issue should better be titled: "Cancelling a build should not abort older builds in sight of the same milestone". I'm having the same problem as the reporting user. I have setup a build-pipeline that waits for user approvals before deploying my application to my QA, STAGING and PRODUCTION environments, respectively. The situation is this: There are multiple builds waiting for an approval to deploy to STAGING, so all of them are currently in sight of the same previous milestone (e.g. "deployed to QA"). I abort the newest build, because it didn't pass quality requirements on QA, and should never be deployed to STAGING, but I wish for older builds at the same input-step to continue waiting for approval to deploy to STAGING. The bad build gets cancelled as expected, but the milestone plugin subsequently performs some clean-up including aborting all other builds in sight of the same milestone (namely "deployed to QA"). This is not the expected behavior, because the just cancelled build did not progress to the next milestone in order to be allowed to abort its siblings.   I believe, this behaviour is due to this: https://github.com/jenkinsci/pipeline-milestone-step-plugin/blob/ab24d126caaad2c507ec0d26b7cb87d314e1f296/src/main/java/org/jenkinsci/plugins/pipeline/milestone/MilestoneStepExecution.java#L189 Which is only ever executed from here: https://github.com/jenkinsci/pipeline-milestone-step-plugin/blob/ab24d126caaad2c507ec0d26b7cb87d314e1f296/src/main/java/org/jenkinsci/plugins/pipeline/milestone/MilestoneStepExecution.java#L330  

          This is pretty undesirable behavior nor is it documented as far as I can tell. I would call it Major, not Minor.  to Kai's suggestion of updating the title.

          Dharma Indurthy added a comment - This is pretty undesirable behavior nor is it documented as far as I can tell. I would call it Major, not Minor.  to Kai's suggestion of updating the title.

          Justin Vallon added a comment -

          The behavior seems to contradict the documentation. I have a sample pipeline that has a single milestone and an alternate slow and fast phase at the end of the build. If a fast job completes, it aborts all the (preceding) jobs that are slow. It seems to treat job completion as exiting the milestone, and killing off the older builds because they were caught.

          However, in the case of SUCCESS (or possibly failure, as this ticket describes), the job has not advanced to the next milestone, it has merely exited the current one because the job is complete. This might be a corner case in the documentation (what if a job completes), but it seems that a FAILURE build should not kill off older builds that have passed the same milestone.

          If a user really wants to kill off older builds in case of success, the script could simply add milestone(ordinal:999, label: "done") to the end of the script. Passing into 999 would then kill off any earlier builds.

          Justin Vallon added a comment - The behavior seems to contradict the documentation. I have a sample pipeline that has a single milestone and an alternate slow and fast phase at the end of the build. If a fast job completes, it aborts all the (preceding) jobs that are slow. It seems to treat job completion as exiting the milestone, and killing off the older builds because they were caught. However, in the case of SUCCESS (or possibly failure, as this ticket describes), the job has not advanced to the next milestone, it has merely exited the current one because the job is complete. This might be a corner case in the documentation (what if a job completes), but it seems that a FAILURE build should not kill off older builds that have passed the same milestone. If a user really wants to kill off older builds in case of success, the script could simply add milestone(ordinal:999, label: "done") to the end of the script. Passing into 999 would then kill off any earlier builds.

          Justin Vallon added a comment -

          I think the build-finished behavior here is the same as JENKINS-50744.

          Justin Vallon added a comment - I think the build-finished behavior here is the same as JENKINS-50744 .

            Unassigned Unassigned
            taylorp36 Taylor Patton
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: