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

Need another pubsub event to indicate that a job run has actually started doing some work

    XMLWordPrintable

Details

    • 1.0-pre-beta-1, 1.0-beta-1, pacific, atlantic, 1.0-b05/b-06

    Description

      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"

      Attachments

        Activity

          cliffmeyers Cliff Meyers created issue -
          cliffmeyers Cliff Meyers made changes -
          Field Original Value New Value
          Epic Link JENKINS-35737 [ 171801 ]
          cliffmeyers Cliff Meyers made changes -
          Link This issue blocks JENKINS-37379 [ JENKINS-37379 ]
          jamesdumay James Dumay made changes -
          Sprint 1.0-pre-beta-1 [ 86 ]
          Priority Major [ 3 ] Blocker [ 1 ]
          jamesdumay James Dumay made changes -
          Assignee Tom FENNELLY [ tfennelly ]
          jamesdumay James Dumay made changes -
          Rank Ranked higher
          tfennelly Tom FENNELLY made changes -
          Summary Pipeline jobs fire SSE "job started" events prematurely when classic UI shows the runs as "queued" Need another pubsub event to indicate that a job run has actually started doing some work
          tfennelly Tom FENNELLY made changes -
          Description 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 [~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.
          tfennelly Tom FENNELLY made changes -
          Component/s sse-gateway-plugin [ 21477 ]
          tfennelly Tom FENNELLY made changes -
          Description 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.
          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.
          tfennelly Tom FENNELLY made changes -
          Description 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.
          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"
          tfennelly Tom FENNELLY added a comment -

          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.

          tfennelly Tom FENNELLY added a comment - 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.
          michaelneale Michael Neale made changes -
          Priority Blocker [ 1 ] Major [ 3 ]
          michaelneale Michael Neale added a comment -

          cliffmeyers is this blocking favourite realtime stuff?

          michaelneale Michael Neale added a comment - cliffmeyers is this blocking favourite realtime stuff?
          jamesdumay James Dumay made changes -
          Priority Major [ 3 ] Critical [ 2 ]
          jamesdumay James Dumay made changes -
          Sprint 1.0-pre-beta-1 [ 86 ] 1.0-pre-beta-1, 1.0-beta-1 [ 86, 96 ]
          michaelneale Michael Neale made changes -
          Link This issue blocks JENKINS-37379 [ JENKINS-37379 ]
          michaelneale Michael Neale added a comment -

          Should really see what cliff cooks up on JENKINS-37379 - before tackling this. May not be needed.

          michaelneale Michael Neale added a comment - Should really see what cliff cooks up on JENKINS-37379 - before tackling this. May not be needed.
          michaelneale Michael Neale made changes -
          Link This issue is blocked by JENKINS-37379 [ JENKINS-37379 ]
          cliffmeyers Cliff Meyers added a comment -

          tfennelly: yep, let me see if I can unblock it myself, rather than having to make the pub/sub stuff more involved. Will let you know once I get to JENKINS-37379, should be later this week.

          cliffmeyers Cliff Meyers added a comment - tfennelly : yep, let me see if I can unblock it myself, rather than having to make the pub/sub stuff more involved. Will let you know once I get to JENKINS-37379 , should be later this week.
          cliffmeyers Cliff Meyers made changes -
          Link This issue is blocked by JENKINS-37379 [ JENKINS-37379 ]
          cliffmeyers Cliff Meyers made changes -
          Link This issue is related to JENKINS-37379 [ JENKINS-37379 ]
          jamesdumay James Dumay made changes -
          Sprint 1.0-pre-beta-1, 1.0-beta-1 [ 86, 96 ] 1.0-pre-beta-1, 1.0-beta-1, 1.0-b05/b-06 [ 86, 96, 111 ]
          jamesdumay James Dumay made changes -
          Rank Ranked higher
          jamesdumay James Dumay made changes -
          Rank Ranked higher
          jamesdumay James Dumay made changes -
          Sprint 1.0-pre-beta-1, 1.0-beta-1, 1.0-b05/b-06 [ 86, 96, 111 ] 1.0-pre-beta-1, 1.0-beta-1, 26-september, 1.0-b05/b-06 [ 86, 96, 101, 111 ]
          michaelneale Michael Neale made changes -
          Sprint 1.0-pre-beta-1, 1.0-beta-1, pacific, 1.0-b05/b-06 [ 86, 96, 101, 111 ] 1.0-pre-beta-1, 1.0-beta-1, pacific, atlantic, 1.0-b05/b-06 [ 86, 96, 101, 106, 111 ]
          michaelneale Michael Neale added a comment -

          cliffmeyers is this something you still want tom to take a look at ?

          michaelneale Michael Neale added a comment - cliffmeyers is this something you still want tom to take a look at ?
          michaelneale Michael Neale made changes -
          Rank Ranked lower
          cliffmeyers Cliff Meyers made changes -
          Link This issue is related to JENKINS-37379 [ JENKINS-37379 ]
          cliffmeyers Cliff Meyers added a comment - - edited

          No, I believe that once JENKINS-38540 and JENKINS-37379 are implemented that this issue will be unnecessary.

          cliffmeyers Cliff Meyers added a comment - - edited No, I believe that once JENKINS-38540 and JENKINS-37379 are implemented that this issue will be unnecessary.
          tfennelly Tom FENNELLY added a comment -

          I can't see how these fix the underlying issue, but if it saves me doing something then

          tfennelly Tom FENNELLY added a comment - I can't see how these fix the underlying issue, but if it saves me doing something then
          michaelneale Michael Neale added a comment -

          lets close this until we know it is needed.

          michaelneale Michael Neale added a comment - lets close this until we know it is needed.
          michaelneale Michael Neale made changes -
          Resolution Won't Fix [ 2 ]
          Status Open [ 1 ] Closed [ 6 ]

          People

            tfennelly Tom FENNELLY
            cliffmeyers Cliff Meyers
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: