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

Milestone option to coalesce queue items while awaiting executor


    • Similar Issues:


      Currently Pipeline builds will almost always start running immediately upon entering the queue (unless you disable concurrent builds altogether), since the Groovy code itself does not require a heavyweight executor.

      Unfortunately this makes it impossible to reproduce a sometimes desirable behavior of freestyle projects, which is queue coalescing: cf. QueueAction, FoldableAction, and ScheduleResult.Existing. The main use case is running only as many concurrent builds as available executors permit, coalescing SCM commits where necessary, while tracking Cause.

      I would suggest this be implemented as an option to the milestone step. For example, if your script is written like

      milestone number: 1, queue: true
      node {
        milestone 2
        checkout scm
        sh 'make'

      and build #1 is running in node while #2 is running but waiting for an executor, if the same job is added to the queue again, rather than immediately starting build #3, Existing should be returned from schedule2 and any FoldableAction in #2 retroactively updated. Once an executor frees up and #2 makes it to the second milestone, new builds can be scheduled again.

      Not sure if this is implementable using current core APIs. QueueDecisionHandler can only return Refused; we would like an option to return Existing instead (or simply take over the ScheduleResult).


          Issue Links


            There are no comments yet on this issue.


              • Assignee:
                amuniz Antonio Muñiz
                jglick Jesse Glick
              • Votes:
                1 Vote for this issue
                2 Start watching this issue


                • Created: