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

Activity tabs Run id column should expand to fit value

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • blueocean-plugin
    • None

      First of all thanks for the new Blue Ocean 1.1 features, like supporting "Custom run names and descriptions".

      See screenshot: we are admittedly using quite long build display names, e.g. "20170613-161100-rev134098" (i.e. "<date>-<time>-rev<SVN revision>")

          [JENKINS-44869] Activity tabs Run id column should expand to fit value

          James Dumay added a comment -

          reinholdfuereder you're most welcome. We are in the process of integrating a new table design which would make it easier for us to revisit this.

          Could you also share a screenshot of the same pipeline in Jenkins Classic? I'd like to see how much space we provide there and what people might expect us to provide.

          James Dumay added a comment - reinholdfuereder you're most welcome. We are in the process of integrating a new table design which would make it easier for us to revisit this. Could you also share a screenshot of the same pipeline in Jenkins Classic? I'd like to see how much space we provide there and what people might expect us to provide.

          James Dumay added a comment -

          reinholdfuereder what is the most significant part of the run name? I would assume the end? What if we reversed the ellipsis so that it appeared at the beginning?

          James Dumay added a comment - reinholdfuereder what is the most significant part of the run name? I would assume the end? What if we reversed the ellipsis so that it appeared at the beginning?

          This should be the relevant screenshot of the same pipeline in Jenkins Classic:

          Concerning "the most significant part of the run name": yes, presumably it would be the end; however, normally, I only use this view for "rough" navigation based on dates (which is the first part of the run name); because once an exact run is of interest and I need to navigate to it, then I have received a notification with the exact link to this particular run anyway. Hope that makes some sense

          Reinhold Füreder added a comment - This should be the relevant screenshot of the same pipeline in Jenkins Classic: Concerning "the most significant part of the run name": yes, presumably it would be the end; however, normally, I only use this view for "rough" navigation based on dates (which is the first part of the run name); because once an exact run is of interest and I need to navigate to it, then I have received a notification with the exact link to this particular run anyway. Hope that makes some sense

          James Dumay added a comment -

          reinholdfuereder where I am going with this is that we can expand the size for your use case but that might not fit other peoples. I don't have a good answer for this yet. Thanks for the screenshots

          James Dumay added a comment - reinholdfuereder where I am going with this is that we can expand the size for your use case but that might not fit other peoples. I don't have a good answer for this yet. Thanks for the screenshots

          jamesdumay thanks for your efforts

          Reinhold Füreder added a comment - jamesdumay thanks for your efforts

          James Dumay added a comment -

          reinholdfuereder no problems. Ill figure this out and update the ticket.

          James Dumay added a comment - reinholdfuereder no problems. Ill figure this out and update the ticket.

          jamesdumay As I almost filed a duplicate of this issue: any updates/progress/hope?

          Reinhold Füreder added a comment - jamesdumay As I almost filed a duplicate of this issue: any updates/progress/hope?

          Tony Hoyle added a comment -

          Even our (relatively) short build numbers eg '9.0.2.19007' don't fit in the current layout.  The tooltip works but it's annoying as there's no way to see the information in a quick glance.

          Could a quick fix just be to make it configurable by a parameter somewhere until the 'proper' fix is done?  

          Ideally in the future resizeable by dragging in the UI, but I guess that depends on the capabilities of the javascript library in use.

          Tony Hoyle added a comment - Even our (relatively) short build numbers eg '9.0.2.19007' don't fit in the current layout.  The tooltip works but it's annoying as there's no way to see the information in a quick glance. Could a quick fix just be to make it configurable by a parameter somewhere until the 'proper' fix is done?   Ideally in the future resizeable by dragging in the UI, but I guess that depends on the capabilities of the javascript library in use.

          jamesdumay Any updates on this issue? I claim this little issue is really, really worth being solved, or at least a workaround could be potentially very cheap to implement?

          Naive workaround for calculation of table column width:

          int width = Math.max(<currentWidth of I think 92px>, Math.min(maximumWidth that should not be exceeded which may be ~250>, <width needed for full display of latest build display name because that might be the biggest build number or in my use case just about as long as all the others>)

          Reinhold Füreder added a comment - jamesdumay Any updates on this issue? I claim this little issue is really, really worth being solved, or at least a workaround could be potentially very cheap to implement? Naive workaround for calculation of table column width: int width = Math .max(<currentWidth of I think 92px>, Math .min(maximumWidth that should not be exceeded which may be ~250>, <width needed for full display of latest build display name because that might be the biggest build number or in my use case just about as long as all the others>)

          Thorsten Scherler added a comment - reinholdfuereder are you using https://wiki.jenkins.io/display/JENKINS/Version+Number+Plugin or https://wiki.jenkins.io/display/JENKINS/Build+Name+Setter+Plugin

          tscherler Actually I am not using any of these plugins, but I have a little helper method in my Jenkins shared pipeline library that does it "directly":

          /*script.*/currentBuild.displayName = ...
          

          Reinhold Füreder added a comment - tscherler Actually I am not using any of these plugins, but I have a little helper method in my Jenkins shared pipeline library that does it "directly": /*script.*/ currentBuild.displayName = ...

          Naively pinging tscherler and michaelneale to politely ask for considering this issue as it might be a very low hanging fruit for an IMHO major BO usability improvement... (Presumably others will classify this as "getting on one's nervers" )

          Reinhold Füreder added a comment - Naively pinging tscherler and michaelneale to politely ask for considering this issue as it might be a very low hanging fruit for an IMHO major BO usability improvement... (Presumably others will classify this as "getting on one's nervers" )

          Michael Neale added a comment -

          halkeye nicu is his something to consider as a quickie? 

          Michael Neale added a comment - halkeye nicu is his something to consider as a quickie? 

          Josh McDonald added a comment -

          It's not really as easy to fix as it first seems, as browsers really take some time to let you know the size of things, and if you change the sizing of one of their containing elements in response to same, you invalidate all the sizes of everything again and you risk the potential for endless loops and constantly shimmying controls, which nobody wants

          Josh McDonald added a comment - It's not really as easy to fix as it first seems, as browsers really take some time to let you know the size of things, and if you change the sizing of one of their containing elements in response to same, you invalidate all the sizes of everything again and you risk the potential for endless loops and constantly shimmying controls, which nobody wants

          Thanks for your considerations and thoughts; and also sorry for my naiveness...

          However, with respect to your hints regarding problems of dynamics:

          • Would it be possible to really do this statically in that the column width is calculated/fixed before the rendering, based on the width needed for rendering solely either the current or maybe the previous build's ID (plus a small tolerance) and of course not exceeding (i.e. limited to) a maximum value to avoid breaking the layout completely?

          Reinhold Füreder added a comment - Thanks for your considerations and thoughts; and also sorry for my naiveness... However, with respect to your hints regarding problems of dynamics: Would it be possible to really do this statically in that the column width is calculated/fixed before the rendering , based on the width needed for rendering solely either the current or maybe the previous build's ID (plus a small tolerance) and of course not exceeding (i.e. limited to) a maximum value to avoid breaking the layout completely?

          Michael Neale added a comment -

          I don't think it would know the size until after something has been rendered, and then then the browser can take it's sweet time. 

           

          However, given we know what ids normally are, if they are anything but numeric in the data set returned - perhaps could just change the width to something that is "probably" wide enough for those cases (99% of people will be numeric and fine)? A really brain dead heuristic. 

          Michael Neale added a comment - I don't think it would know the size until after something has been rendered, and then then the browser can take it's sweet time.    However, given we know what ids normally are, if they are anything but numeric in the data set returned - perhaps could just change the width to something that is "probably" wide enough for those cases (99% of people will be numeric and fine)? A really brain dead heuristic. 

          Gavin Mogan added a comment -

          Yea, as above mentioned, its not a quick easy win. The tables are pretty fixed with, and I think changeing the run id is a pretty niche item. 

           

          That being said, fixing JENKINS-46521 might help so that the commit id is no longer -, and would no longer be needed in the build id? maybe?

          Gavin Mogan added a comment - Yea, as above mentioned, its not a quick easy win. The tables are pretty fixed with, and I think changeing the run id is a pretty niche item.    That being said, fixing  JENKINS-46521 might help so that the commit id is no longer -, and would no longer be needed in the build id? maybe?

          Oh yes, this sounds like a great idea:

          • hiding the "Commit" column for a non-multi branch pipeline in favour of showing the full build display number in the BO's activity tab "Run" id column (see JENKINS-44869) would be ideal/fine for me
            • because I have the commit ID (SVN revision or shortened GIT commit hash) as suffix of my therefore quite long build display number, e.g. "20170613-161100-rev134098" (i.e. "<date>-<time>-rev<SVN revision>")

          Reinhold Füreder added a comment - Oh yes, this sounds like a great idea: hiding the "Commit" column for a non-multi branch pipeline in favour of showing the full build display number in the BO's activity tab "Run" id column (see JENKINS-44869 ) would be ideal/fine for me because I have the commit ID (SVN revision or shortened GIT commit hash) as suffix of my therefore quite long build display number, e.g. "20170613-161100-rev134098" (i.e. "<date>-<time>-rev<SVN revision>")

          Michael Neale added a comment -

          reinholdfuereder having trouble following - any chance you can mock it up what it may look like in your case? 

          Michael Neale added a comment - reinholdfuereder having trouble following - any chance you can mock it up what it may look like in your case? 

          michaelneale Sorry for the confusion. I referred to halkeye's comment and JENKINS-46521

          Mock up:

          • Now/old:
          • Future/new:

          Reinhold Füreder added a comment - michaelneale Sorry for the confusion. I referred to halkeye 's comment and JENKINS-46521 Mock up: Now/old: Future/new:

          does anybody have a solution yet? I'd like to see the RUN column to take up more space (1.5x or 2x)

          Peter Niederlag added a comment - does anybody have a solution yet? I'd like to see the RUN column to take up more space (1.5x or 2x)

          Alan Champion added a comment - - edited

          Complementary to JENKINS-46657 allowing currentBuild.displayName, where the RUN column is no longer simply #1-1000, this now needs to accommodate typical build/release names, which potentially may be prefixed by target environment and/or dynamic job status.

          In our system, using the MESSAGE column description as an "alternative" is inadequate, as this shows "Started by <user>/upstream job" or "Replayed #?".

          So, the expectation is that RUN column shows the full currentBuild.displayName buildName, whatever width it needs to be.

          Thanks for your attention to this detail.

          Alan Champion added a comment - - edited Complementary to JENKINS-46657  allowing currentBuild.displayName, where the RUN column is no longer simply #1-1000, this now needs to accommodate typical build/release names, which potentially may be prefixed by target environment and/or dynamic job status. In our system, using the MESSAGE column description as an "alternative" is inadequate, as this shows "Started by <user>/upstream job" or "Replayed #?". So, the expectation is that RUN column shows the  full  currentBuild.displayName buildName, whatever width it needs to be. Thanks for your attention to this detail.

            Unassigned Unassigned
            reinholdfuereder Reinhold Füreder
            Votes:
            7 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: