-
Bug
-
Resolution: Won't Fix
-
Critical
-
None
-
-
1.0-pre-beta-1, 1.0-beta-1, pacific, atlantic, 1.0-b05/b-06
From cliffmeyers
The server side events for Pipeline jobs fire immediately. If the user presses the "Build Now" from Classic UI eight times, the Blue Ocean UI will receive events showing status of "QUEUED", "ALLOCATED" and "RUNNING" for all eight jobs immediately. Meanwhile the classic UI shows six of the jobs as queued, while two are running (what the user would expect with only two executors active.
Some implementation ideas, from cliffmeyers
Introduce custom logic in "pubsub-light" SyncRunListener to not fire start events for Pipeline jobs. Create some kind of new listener - "PipelineSyncRunListener, possibly in a new module like pipeline-pubsub-light" - when receives notification of Pipeline's step/stage start and then produces the proper start event as in SyncRunListener.
and impl ideas from tfennelly
Keep the existing "started" event but add a new event called "running" which the Blue Ocean UI would use to transition the job from "queued" to "running"
[JENKINS-37340] Need another pubsub event to indicate that a job run has actually started doing some work
| Epic Link | New: JENKINS-35737 [ 171801 ] |
| Link | New: This issue blocks JENKINS-37379 [ JENKINS-37379 ] |
| Sprint | New: 1.0-pre-beta-1 [ 86 ] | |
| Priority | Original: Major [ 3 ] | New: Blocker [ 1 ] |
| Assignee | New: Tom FENNELLY [ tfennelly ] |
| Rank | New: Ranked higher |
| Summary | Original: Pipeline jobs fire SSE "job started" events prematurely when classic UI shows the runs as "queued" | New: Need another pubsub event to indicate that a job run has actually started doing some work |
| Description |
Original:
From [~cliffmeyers] The server side events for Pipeline jobs fire immediately. If the user presses the "Build Now" from Classic UI eight times, the Blue Ocean UI will receive events showing status of "QUEUED", "ALLOCATED" and "RUNNING" for all eight jobs immediately. Meanwhile the classic UI shows six of the jobs as queued, while two are running (what the user would expect with only two executors active. Some implementation ideas, from [~cliffmeyers] Introduce custom logic in "pubsub-light" SyncRunListener to not fire start events for Pipeline jobs. Create some kind of new listener - "PipelineSyncRunListener, possibly in a new module like pipeline-pubsub-light" - when receives notification of Pipeline's step/stage start and then produces the proper start event as in SyncRunListener. and impl ideas from [~tfennelly] Keep the existing "started" event but add a new event called "running" which the Blue Ocean UI would use to transition the job from "queued" to "running" |
New:
From [~cliffmeyers] The server side events for Pipeline jobs fire immediately. If the user presses the "Build Now" from Classic UI eight times, the Blue Ocean UI will receive events showing status of "QUEUED", "ALLOCATED" and "RUNNING" for all eight jobs immediately. Meanwhile the classic UI shows six of the jobs as queued, while two are running (what the user would expect with only two executors active. Some implementation ideas, from [~cliffmeyers] Introduce custom logic in "pubsub-light" SyncRunListener to not fire start events for Pipeline jobs. Create some kind of new listener - "PipelineSyncRunListener, possibly in a new module like pipeline-pubsub-light" - when receives notification of Pipeline's step/stage start and then produces the proper start event as in SyncRunListener. and impl ideas from [~tfennelly] Keep the existing "started" event but add a new event called "running" which the Blue Ocean UI would use to transition the job from "queued" to "running" From [~tfennelly] ... the run_started event fires at the right time i.e. when the run moves out of the queue. The problem with pipeline runs is that this happens immediately as the run creates a "lightweight" run task that's not really doing anything yet. We need another pubsub event to let listeners know when the run has actually started "running" some of the pipeline steps. Please remember that the pubsub stuff should remain generic i.e. not specific to the UI needs, so when we hit things like this we need to address them in a general way Vs just having the UI goggles on. |
| Component/s | New: sse-gateway-plugin [ 21477 ] |
| Description |
Original:
From [~cliffmeyers] The server side events for Pipeline jobs fire immediately. If the user presses the "Build Now" from Classic UI eight times, the Blue Ocean UI will receive events showing status of "QUEUED", "ALLOCATED" and "RUNNING" for all eight jobs immediately. Meanwhile the classic UI shows six of the jobs as queued, while two are running (what the user would expect with only two executors active. Some implementation ideas, from [~cliffmeyers] Introduce custom logic in "pubsub-light" SyncRunListener to not fire start events for Pipeline jobs. Create some kind of new listener - "PipelineSyncRunListener, possibly in a new module like pipeline-pubsub-light" - when receives notification of Pipeline's step/stage start and then produces the proper start event as in SyncRunListener. and impl ideas from [~tfennelly] Keep the existing "started" event but add a new event called "running" which the Blue Ocean UI would use to transition the job from "queued" to "running" From [~tfennelly] ... the run_started event fires at the right time i.e. when the run moves out of the queue. The problem with pipeline runs is that this happens immediately as the run creates a "lightweight" run task that's not really doing anything yet. We need another pubsub event to let listeners know when the run has actually started "running" some of the pipeline steps. Please remember that the pubsub stuff should remain generic i.e. not specific to the UI needs, so when we hit things like this we need to address them in a general way Vs just having the UI goggles on. |
New:
From [~cliffmeyers] The server side events for Pipeline jobs fire immediately. If the user presses the "Build Now" from Classic UI eight times, the Blue Ocean UI will receive events showing status of "QUEUED", "ALLOCATED" and "RUNNING" for all eight jobs immediately. Meanwhile the classic UI shows six of the jobs as queued, while two are running (what the user would expect with only two executors active. Some implementation ideas, from [~cliffmeyers] Introduce custom logic in "pubsub-light" SyncRunListener to not fire start events for Pipeline jobs. Create some kind of new listener - "PipelineSyncRunListener, possibly in a new module like pipeline-pubsub-light" - when receives notification of Pipeline's step/stage start and then produces the proper start event as in SyncRunListener. and impl ideas from [~tfennelly] Keep the existing "started" event but add a new event called "running" which the Blue Ocean UI would use to transition the job from "queued" to "running" --------------------------------------------- From [~tfennelly] ... the run_started event fires at the right time i.e. when the run moves out of the queue. The problem with pipeline runs is that this happens immediately as the run creates a "lightweight" run task that's not really doing anything yet. We need another pubsub event to let listeners know when the run has actually started "running" some of the pipeline steps. Please remember that the pubsub stuff should remain generic i.e. not specific to the UI needs, so when we hit things like this we need to address them in a general way Vs just having the UI goggles on. |