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

          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: