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

REGRESSION: activity/branch run status is not updated after closing karaoke mode

    Details

    • Sprint:
      tasman
    • Similar Issues:

      Description

      After following along a pipeline to completion, if you close the completed results window, it still shows up as running in Branches tab (and activities). The toast never goes away either.

      To reproduce:

      Setup the kzantow/failure-project multibranch pipeline.
      Open the pipeline and branches tab
      Run the "michaelneale" branch from the branches tab
      Click into the running job
      Wait for it to finish (karaoke mode)
      Close the results screen to return to branches - not that the pipeline says it is still running in the listing, but it isn't.

      Repeat the above for a non multibranch pipeline (script below) and you can see the same from the activity tab.

      The ATH should be enhanced to cover this case (it looks already for the result screen changing state, but needs to close the tab and check the item in the listing has stopped running).

      Example:
      https://media.giphy.com/media/l0MYSXp5f8MCA9TAQ/giphy.gif

      Pipeline:

          node {
              sh "echo 42"
              sh "sleep 8"
              sh "echo 43"
              
          }
          
      }
      

      YOu can see it happening here:

      https://media.giphy.com/media/l2JhKwdAFvGv60PUA/giphy.gif

        Attachments

          Activity

          Hide
          michaelneale Michael Neale added a comment - - edited

          Ivan Meredith James Dumay this seems to have been broken in this commit (best I can tell, but I could be wrong):

          https://github.com/jenkinsci/blueocean-plugin/commit/3f283a236008749b3a1fb6e60ace974e8ba6dd5c

          I thought Ivan Meredith may know what it is just at a glance.

          Show
          michaelneale Michael Neale added a comment - - edited Ivan Meredith James Dumay this seems to have been broken in this commit (best I can tell, but I could be wrong): https://github.com/jenkinsci/blueocean-plugin/commit/3f283a236008749b3a1fb6e60ace974e8ba6dd5c I thought Ivan Meredith may know what it is just at a glance.
          Hide
          jamesdumay James Dumay added a comment -

          Good catch!

          Show
          jamesdumay James Dumay added a comment - Good catch!
          Hide
          jamesdumay James Dumay added a comment -

          This needs more ATH

          Show
          jamesdumay James Dumay added a comment - This needs more ATH
          Hide
          michaelneale Michael Neale added a comment -

          Ivan Meredith so it looks like this isn't solved by the mobx change - are you going to look at it or need some help?

          Show
          michaelneale Michael Neale added a comment - Ivan Meredith so it looks like this isn't solved by the mobx change - are you going to look at it or need some help?
          Hide
          cliffmeyers Cliff Meyers added a comment -

          Michael Neale I am fairly confident this was fixed in https://github.com/jenkinsci/blueocean-plugin/pull/614 . Looking at both giphy, the URL does not update after closing the modal. This means the content on the screen is actually the cloned "background DOM" that is used to prevent the "flash" when the modal opens and closes - which is disconnected from React and won't be updated. Perhaps you'd be willing to test this one more time and close if not repro?

          Show
          cliffmeyers Cliff Meyers added a comment - Michael Neale I am fairly confident this was fixed in https://github.com/jenkinsci/blueocean-plugin/pull/614 . Looking at both giphy, the URL does not update after closing the modal. This means the content on the screen is actually the cloned "background DOM" that is used to prevent the "flash" when the modal opens and closes - which is disconnected from React and won't be updated. Perhaps you'd be willing to test this one more time and close if not repro?
          Hide
          jamesdumay James Dumay added a comment -

          I can confirm this has been fixed. Nice one!

          Show
          jamesdumay James Dumay added a comment - I can confirm this has been fixed. Nice one!
          Hide
          cliffmeyers Cliff Meyers added a comment -

          #614 was a 4-for-1 special

          Show
          cliffmeyers Cliff Meyers added a comment - #614 was a 4-for-1 special

            People

            • Assignee:
              cliffmeyers Cliff Meyers
              Reporter:
              michaelneale Michael Neale
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: