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

CauseOfBlockage of items in Queue is extremely verbose

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • Jenkins:2.46

      When hovering over a queued item to check on the cause of blockage, the UI displays an extremely large text area showing something like the following:

      <nodeA> doesn’t have label <label>; <nodeB> doesn’t have label <label>; ...
      

      The text contains every single node in the Jenkins instance. And on some systems completely fills the browser window obscuring all other text.

      But it is intermittent and on the next refresh (probably by the automatic queue maintenance), the cause of blockage shows more simple cause like "Waiting for the next available executor for <label1>" (see simple-cause.png ).

      (For that reason I have not been able to capture a screenshot yet. As soon as I can I will attach it to this ticket)

      *Sensitive Information*

      It sometimes appears that build parameters shows up in that text.

      *Related Issues*

      This seems related to the improvement made in https://issues.jenkins-ci.org/browse/JENKINS-38514.

          [JENKINS-45927] CauseOfBlockage of items in Queue is extremely verbose

          Daniel Beck added a comment -

          It sometimes appears that build parameters shows up in that text

          … visible to people with read access to the job. How is that a problem? They can just wait for the build to exist, then look at the parameters page.

          Daniel Beck added a comment - It sometimes appears that build parameters shows up in that text … visible to people with read access to the job. How is that a problem? They can just wait for the build to exist, then look at the parameters page.

          danielbeck right I missed that point. Therefore showing parameters is not a security concern in that case

          Allan BURDAJEWICZ added a comment - danielbeck right I missed that point. Therefore showing parameters is not a security concern in that case

          Steven Christenson added a comment - - edited

          Showing parameters is unexpected. Also, as I am an Admin 100% of the time, it's not clear to me whether an average user can see the "Build Queue". In any case, on our system the size of the text is so large that when you hover over it, it completely fills the browser window.

          I attached a screenshot with redactions.

          Steven Christenson added a comment - - edited Showing parameters is unexpected. Also, as I am an Admin 100% of the time, it's not clear to me whether an average user can see the "Build Queue". In any case, on our system the size of the text is so large that when you hover over it, it completely fills the browser window. I attached a screenshot with redactions.

          Daniel Beck added a comment -

          Showing parameters is unexpected

          How else would you identify exactly what build (when there's parallel builds enabled) is waiting in the queue to be able to e.g. decide which queue item to cancel? This has existed forever and will not be changed. E.g. JENKINS-17454 is a popular issue (for back then) related to not showing the parameters everywhere queue items were listed.

          Also, as I am an Admin 100% of the time, it's not clear to me whether an average user can see the "Build Queue".

          Queue items for the job in the queue are shown if and only if the current user is able to view the job and its builds.

          In any case, on our system the size of the text is so large that when you hover over it, it completely fills the browser window.

          Right, this is an issue.

          Daniel Beck added a comment - Showing parameters is unexpected How else would you identify exactly what build (when there's parallel builds enabled) is waiting in the queue to be able to e.g. decide which queue item to cancel? This has existed forever and will not be changed. E.g. JENKINS-17454 is a popular issue (for back then) related to not showing the parameters everywhere queue items were listed. Also, as I am an Admin 100% of the time, it's not clear to me whether an average user can see the "Build Queue". Queue items for the job in the queue are shown if and only if the current user is able to view the job and its builds. In any case, on our system the size of the text is so large that when you hover over it, it completely fills the browser window. Right, this is an issue.

          Alex Taylor added a comment -

          danielbeck would it not make more sense to just count the number of agents which do not have the label and then return that number? Then you could find out the names(if needed) from the build console log itself rather than from the hover over in the build queue.

          Alex Taylor added a comment - danielbeck would it not make more sense to just count the number of agents which do not have the label and then return that number? Then you could find out the names(if needed) from the build console log itself rather than from the hover over in the build queue.

          Daniel Beck added a comment - - edited

          ataylor Agree with verbosity of the Cause of Blockage isn't useful. Note I've only explained why having parameters is valuable.

          Doesn't have to be a tool tip (perhaps it's time for Queue to get an index.jelly ) but it needs to be shown somewhere.

          Daniel Beck added a comment - - edited ataylor Agree with verbosity of the Cause of Blockage isn't useful. Note I've only explained why having parameters is valuable. Doesn't have to be a tool tip (perhaps it's time for Queue to get an index.jelly ) but it needs to be shown somewhere.

          Alex Taylor added a comment -

          OK there is a way to workaround this issue by installing the Simple Theme Plugin which is to add a Theme Element of `Extra CSS` under `Manage Jenkins> Configre System` which contains the following data:

          .build-details { 
          max-height:100px !important; 
          overflow: auto !important; 
          width:100% !important; 
          }
          
          #tt { 
          overflow:hidden;max-height:200px; 
          }
          

          This will restrict any pop up box to a certain size and truncate the rest which stops the UI from being blocked by this popup

          Alex Taylor added a comment - OK there is a way to workaround this issue by installing the Simple Theme Plugin which is to add a Theme Element of `Extra CSS` under `Manage Jenkins> Configre System` which contains the following data: .build-details { max-height:100px !important; overflow: auto !important; width:100% !important; } #tt { overflow:hidden;max-height:200px; } This will restrict any pop up box to a certain size and truncate the rest which stops the UI from being blocked by this popup

            Unassigned Unassigned
            allan_burdajewicz Allan BURDAJEWICZ
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: