Why is the build history entry represented as multi-line?

In jenkins 2.440, after the default installation, I created a project and executed the copy command with the Execute Windows batch command in the build steps.

Previously, the build history was single-line, but now it is multi-line.

Is it possible to change this?

I don’t think so, but you can create a bug or feature request in Jira. Please include a before and after image. (Or even better provide a PR)

Thank you for your feedback.

I checked again(war file),

In Jenkins 2.439, Build history is displayed as single-line by default,
Jekkins 2.440, Build history is displayed as multi-line by default.

I’ll ask Jira(?) if it’s a bug or a policy issue.

Jekkins 2.441, Build history is showing up as a single line again.
I don’t think I need to contact Jira(?).

I found something that is dependent on the browser environment.

Mozilla is the same as before(2.439(single), 2.440(multi), 2.441(single)),
In chrome and edge it(2.441) is still displayed as multi-line.

Any news on this?

I have one-line and two-line entries mixed on the same page.
Same in Firefox and Edge, with the twist, that different lines are single or double in FF or Edge. But it is consistent in the same browser. If I open the same project page in FF and then again in a private window in FF, I get the same output (with some build numbers in one line, others in two). Same in Edge (normal and private window, both showing same output)

Jenkins versions is 2.387.2

This is expected as the space is limited.
There is currently work in progress to rewrite this widget here: Rewrite the build history widget by janfaracik · Pull Request #9148 · jenkinsci/jenkins · GitHub

I don’t see how this helps with limited space. Here is a screenshot:


Also, why different behavior between Firefox and Edge?

The current implementation gives a percentage of the width to the build number, the timestamp and optional badges. The logic is quite complex when it tries to decide if it should put everything in one line or in multiple lines and is not doing a good job here.
The new implementation will be much better in this respect.

The behaviour is different because font size might be slightly different between firefox and chrome. The decision if single or multi line can be caused just by 1 px difference in length

Who is making this decision?
I looked at the HTML and the twoline items have a different class than the one line items.
So the server is making it different. Which begs the question, why does it send different HTML to different browsers?

Seems like a super complicated code for what is basically “show two links (and an icon)”.

There can be more than 2 links and an icon. A run can have a different displayname then you no longer have e.g. #3223 but something link my important run, builds can have badges, e.g. when you decide to keep a build forever, it gets an icon, there are plugins that add other badges, e.g. what triggered the build (human, timer, github event, gerrit event, …).
A build can have a description which is shown on an extra line.

The existing logic is limited and as you noticed produces far from optimal results.
You find it here:

But the mentioned pull request will fix those things.

1 Like

I had this experience too (mixed single-line and multi-line).
My experience was as follows

  1. existing build entries were single-line.

  2. after updating the plugin, the job execution became multi-line for new build entries.

  3. after reverting back to the old plugin, the job execution became single-line.

So, when viewed in browsers (Chrome, Edge), the build history was represented as single-multi-single.

In FF, I couldn’t check it.

So, I assumed that the plugin update was the cause and that it was determined at build time as single or multi.

However, based on the comments above, I think I was wrong.