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

Schedule build icon no longer distinguishes in-queue state (regression in 2.321)

    • 2.347, 2.346.1

      Current nightly builds have a severe regression against LTS.
      As I do not monitor nightly regularly, I'm unable to provide exact version when it occurred, but quick scan suggests the root cause is move from gif icons to svg ones.

      In LTS, when you the build is in queue, the "schedule" icon (the clocks) recognize this, and changes to be blinking (clock_anime.gif).
      In nightly, the icon remains same, which enforces one more click from view to job to verify if the build is already queued.

      Note, that the status icon behaves similarly - it shows last status, or moving last status if the job is already running.

      From quick sca nit seems, that al the logic is already in jenkins, only identical icon is drawn, if the build is scheduled and in queue as if it is not in queue (not scheduled or running)

      Note, that the icon do not change, if "build now" (the green arrow/clock.gif) is pressed. The change would happen only after reload given page

          [JENKINS-68303] Schedule build icon no longer distinguishes in-queue state (regression in 2.321)

          Basil Crow added a comment -

          judovana When filing regression bugs, it is helpful to include the steps to reproduce, expected results, and actual results as described in the Issue Reporting documentation. As a courtesy, I have taken the liberty of providing this information below:

          Steps to reproduce

          1. Install Jenkins 2.321.
          2. Install Schedule Build plugin 244.vce2a_2e926127.
          3. Create a Freestyle job and schedule it 1 day in the future.
          4. Go back to the dashboard.

          Expected results

          Note: These are the actual results when running with Jenkins 2.320.

          Observe that on the right there are two icons: a blinking "Schedule a build for ${JOB_NAME}" clock and a non-blinking "Schedule a build" clock.

          Actual results

          Observe that you do not see a blinking "Schedule a build for ${JOB_NAME}" clock on the left anymore. Instead it is replaced with a non-blinking green arrow. The button on the right for "Schedule a build" remains a non-blinking clock as before. It is jarring that one icon would be replaced but not the other. And there is a loss of information because the left icon no longer blinks, thereby no longer distinguishing the in-queue state as reported.

          Observation

          Bisection shows this was caused by JENKINS-68229 in jenkinsci/jenkins#5851.

          Basil Crow added a comment - judovana When filing regression bugs, it is helpful to include the steps to reproduce, expected results, and actual results as described in the Issue Reporting documentation. As a courtesy, I have taken the liberty of providing this information below: Steps to reproduce Install Jenkins 2.321. Install Schedule Build plugin 244.vce2a_2e926127. Create a Freestyle job and schedule it 1 day in the future. Go back to the dashboard. Expected results Note: These are the actual results when running with Jenkins 2.320. Observe that on the right there are two icons: a blinking "Schedule a build for ${JOB_NAME}" clock and a non-blinking "Schedule a build" clock. Actual results Observe that you do not see a blinking "Schedule a build for ${JOB_NAME}" clock on the left anymore. Instead it is replaced with a non-blinking green arrow. The button on the right for "Schedule a build" remains a non-blinking clock as before. It is jarring that one icon would be replaced but not the other. And there is a loss of information because the left icon no longer blinks, thereby no longer distinguishing the in-queue state as reported. Observation Bisection shows this was caused by JENKINS-68229 in jenkinsci/jenkins#5851 .

          jiri vanek added a comment -

          Hi! Deserved rebuke taken. thank you very much for looking into it even with such poor report.

          jiri vanek added a comment - Hi! Deserved rebuke taken. thank you very much for looking into it even with such poor report.

          While I can't offer much spare time to work on this issue at the moment, I'll drop a quick reply how the issue could be addressed nevertheless, incase someone else wants to pick it up:

          From quick sca nit seems, that al the logic is already in jenkins, only identical icon is drawn, if the build is scheduled and in queue as if it is not in queue (not scheduled or running)

          This statement fits well, the logic itself remained untouched in Basil's mentioned PR. Reintroducing the ternary that checks whether the job is queued up or not placing the icon-clock-anime gif restores the regressed behavior.
          However, that would be the bad way, because the clock itself is no longer used in Jenkins itself to trigger a build and subject to removal in future versions of Jenkins in favor of more up to date icons.

          The better approach (in my mind) would be to create a pulsing CSS animation of the play.svg or something similar that indicates the job is queued up. (See progress-animation.less for already existing CSS animations in Jenkins)
           

          Alexander Brandes added a comment - While I can't offer much spare time to work on this issue at the moment, I'll drop a quick reply how the issue could be addressed nevertheless, incase someone else wants to pick it up: From quick sca nit seems, that al the logic is already in jenkins, only identical icon is drawn, if the build is scheduled and in queue as if it is not in queue (not scheduled or running) This statement fits well, the logic itself remained untouched in Basil's mentioned PR. Reintroducing the ternary that checks whether the job is queued up or not placing the icon-clock-anime gif restores the regressed behavior. However, that would be the bad way, because the clock itself is no longer used in Jenkins itself to trigger a build and subject to removal in future versions of Jenkins in favor of more up to date icons. The better approach (in my mind) would be to create a pulsing CSS animation of the play.svg or something similar that indicates the job is queued up. (See progress-animation.less for already existing CSS animations in Jenkins)  

          jiri vanek added a comment -

          Hello!
          Thanx a lot for insight!
          The removal of clocks is expected seeing the svg icons, and I do not expect them be back. Still the logic that the icon will be different or animated if the build is already scheduled remains as valid. Also it is notable, that animated svg icons already have precedent in modern-style jenkins.

          Thanx a lot all!

          jiri vanek added a comment - Hello! Thanx a lot for insight! The removal of clocks is expected seeing the svg icons, and I do not expect them be back. Still the logic that the icon will be different or animated if the build is already scheduled remains as valid. Also it is notable, that animated svg icons already have precedent in modern-style jenkins. Thanx a lot all!

          I opened a PR to have the previous behavior.

          Adrien Lecharpentier added a comment - I opened a PR to have the previous behavior.

          jiri vanek added a comment -

          jiri vanek added a comment - https://github.com/jenkinsci/jenkins/pull/6534

            alecharp Adrien Lecharpentier
            judovana jiri vanek
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: