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

Scheduling a Pipeline build should redirect to the new build, not job, index page

      For traditional Jenkins project types, Build or Build with Parameters pages redirect to the job index page upon submission, since there is no way of knowing how long it will be before the build starts—in general, it will wait in the queue for an executor. In some cases the queue might immediately schedule the build, but often it will not.

      For Pipeline, newly scheduled Run items (as opposed to node blocks) are almost always scheduled immediately, since they merely need a flyweight executor slot on the master node, and there should not be anything stopping them from running. (Plugins can delay or cancel the build using various APIs. The only case I can think of offhand is jenkins.branch.RateLimitBranchProperty.QueueTaskDispatcherImpl.)

      For better usability, we would expect the redirect to go straight to the build page if indeed the build can be scheduled immediately. I suspect this is most easily done in core, even if the biggest benefit is for Pipeline.

      Should also be applied to Replay (or Rebuild) on Pipeline builds.

          [JENKINS-49138] Scheduling a Pipeline build should redirect to the new build, not job, index page

          Jesse Glick added a comment -

          Currently Build does no UI redirect at all (only a 201 for API clients), so its UI would need to be modified without breaking REST compatibility. For example, the POST request in addition to the Location header could optionally include an X-Jenkins-Redirect header which this would need to honor.

          Build with Parameters uses this UI to drive this code which would need to be modified to redirect to a Run.

          Pipeline Replay and Rebuild are easier to modify in the UI layer. Similarly the rebuild plugin.

          In any of these cases it is a bit tricky to tell what kind of redirect is possible, since the Queue does not synchronously process anything in scheduleInternal; it just calls scheduleMaintenance, so even if the quietPeriod == 0 and there is no reason to block the Executor, there will still be a brief delay before the next call to maintain completes. The HTTP response thread could for example item.getFuture().getStartCondition().get(1, SECONDS); or perhaps there could be a more precise API such as QueueListener.onMaintained allowing the scheduling code to determine if the maintain call it triggered in fact resulted in a build; or perhaps scheduleInternal should simply call scheduleMaintenance().get(1, SECONDS) so that schedule2 and similar overloads would wait until the new build had actually started (when it is not delayed or blocked for any reason); or perhaps QueueTaskFuture should get a new Future<Optional<R>> getImmediateStartCondition() which would return a present value only if the maintain call scheduled the item already.

          Jesse Glick added a comment - Currently Build does no UI redirect at all (only a 201 for API clients), so its UI would need to be modified without breaking REST compatibility. For example, the POST request in addition to the Location header could optionally include an X-Jenkins-Redirect header which this  would need to honor. Build with Parameters uses this UI  to drive this code  which would need to be modified to redirect to a Run . Pipeline Replay and Rebuild are easier to modify  in the UI layer. Similarly the rebuild plugin . In any of these cases it is a bit tricky to tell what kind of redirect is possible, since the Queue does not synchronously process anything in scheduleInternal ; it just calls scheduleMaintenance , so even if the quietPeriod == 0 and there is no reason to block the Executor , there will still be a brief delay before the next call to maintain completes. The HTTP response thread could for example item.getFuture().getStartCondition().get(1, SECONDS) ; or perhaps there could be a more precise API such as QueueListener.onMaintained allowing the scheduling code to determine if the maintain call it triggered in fact resulted in a build; or perhaps scheduleInternal should simply call scheduleMaintenance().get(1, SECONDS) so that schedule2 and similar overloads would wait until the new build had actually started (when it is not delayed or blocked for any reason); or perhaps QueueTaskFuture should get a new Future<Optional<R>> getImmediateStartCondition() which would return a present value only if the maintain call scheduled the item already.

          Andrew Bayer added a comment -

          Got a case where this is a hassle over on a PR.

          Andrew Bayer added a comment - Got a case where this is a hassle over on a PR .

          AnneTheAgile added a comment -

          This is a great idea. Even for regular non-pipeline jobs, maybe at the least there could be a message or pause say 20 seconds and if the job hasn't started by then just do nothing stating the job hasn't started yet please be patient.

          It seems to me even pipeline jobs could have an issue if the leader suddenly goes down - it's never 100% sure that there is an immediate build start.

          AnneTheAgile added a comment - This is a great idea. Even for regular non-pipeline jobs, maybe at the least there could be a message or pause say 20 seconds and if the job hasn't started by then just do nothing stating the job hasn't started yet please be patient. It seems to me even pipeline jobs could have an issue if the leader suddenly goes down - it's never 100% sure that there is an immediate build start.

          Jesse Glick added a comment -

          Jesse Glick added a comment - https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/228#discussion_r183927485

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: