Reinhold Füreder 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.

Reinhold Füreder 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 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 thanks for your efforts

Reinhold Füreder no problems. Ill figure this out and update the ticket.

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

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.

James Dumay 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 are you using https://wiki.jenkins.io/display/JENKINS/Version+Number+Plugin or https://wiki.jenkins.io/display/JENKINS/Build+Name+Setter+Plugin

Thorsten Scherler 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 Thorsten Scherler and Michael Neale 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" )

Gavin Mogan Nicolae Pascu is his something to consider as a quickie? 

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?

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. 

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 having trouble following - any chance you can mock it up what it may look like in your case? 

Michael Neale Sorry for the confusion. I referred to Gavin Mogan'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)

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.