-
Improvement
-
Resolution: Unresolved
-
Major
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.
- links to
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.