bc1618ed5b
This alters the behavior of the promote event handler so that it does something useful in independent pipelines as well as dependent. It not only re-orders changes within a pipeline's shared queue (the old behavior), but it also re-orders the shared queue within the pipeline. When used in an independent pipeline, this will give the item an advantage when requesting nodes or semaphores, or starting jobs. This behavior applies to dependent pipelines as well -- the behavior is the same for every pipeline. Restarting jobs for changes in independent pipelines would be counter-productive (and even in dependent pipelines we may have restarted more jobs than necessary if the change at the head wasn't being altered), so it has been altered to only dequeue/enqueue items when necessary to achieve the requested order. The event argument to addChange within the promote method has been changed from the promote event to the original item enqueue event. Methods within the pipeline manager assume that event type is a TriggerEvent rather than a ManagementEvent and could throw some (non-fatal) errors when reporting. Change-Id: Ib4ab855cff27bf8e96aa852333fb4ace656235b4
12 lines
419 B
YAML
12 lines
419 B
YAML
---
|
|
features:
|
|
- |
|
|
The promote administrative action now functions with all pipeline
|
|
managers. Previously it would only have an impact on dependent
|
|
pipelines, but it will now re-order change queues as well as
|
|
changes within any type of pipeline.
|
|
upgrade:
|
|
- |
|
|
The promote administrative action will no longer restart jobs for
|
|
changes which have not been re-ordered within their change queue.
|