Better build hist wrapping

[tfennelly]

2 commits that try make text wrapping in the build history widget a bit nicer:

1. Change the dates to just the time of day and then introduce date separators in the history, so builds from a given day are grouped together. (related to JENKINS-25381 )
2. Introduce zero-width spaces in long words in the build name and description, allowing them to wrap more cleanly.

[tfennelly]

Grrr this is failing on CI and the failure looks to be unrelated to the changes I made (+ builds fine locally).

Failure in current CI run:

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 26.94 sec - in hudson.model.ComputerSetTest
Running hudson.model.QueueTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 51.681 sec - in hudson.model.QueueTest
Running hudson.model.RunParameterDefinitionTest
Tests run: 22, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 701.59 sec <<< FAILURE! - in hudson.model.AbstractProjectTest
testExternalBuildDirectoryRenameDelete(hudson.model.AbstractProjectTest)  Time elapsed: 0.063 sec  <<< ERROR!
java.lang.InterruptedException: null
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:503)
    at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:267)
    at jenkins.InitReactorRunner.run(InitReactorRunner.java:44)
    at jenkins.model.Jenkins.executeReactor(Jenkins.java:914)
    at jenkins.model.Jenkins.<init>(Jenkins.java:813)
    at hudson.model.Hudson.<init>(Hudson.java:83)
    at org.jvnet.hudson.test.HudsonTestCase.newHudson(HudsonTestCase.java:474)
    at org.jvnet.hudson.test.HudsonTestCase.setUp(HudsonTestCase.java:315)
    at junit.framework.TestCase.runBare(TestCase.java:139)
    at org.jvnet.hudson.test.HudsonTestCase.runBare(HudsonTestCase.java:293)
    at junit.framework.TestResult$1.protect(TestResult.java:122)
    at junit.framework.TestResult.runProtected(TestResult.java:142)
    at junit.framework.TestResult.run(TestResult.java:125)
    at junit.framework.TestCase.run(TestCase.java:129)
    at junit.framework.TestSuite.runTest(TestSuite.java:255)
    at junit.framework.TestSuite.run(TestSuite.java:250)
    at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

[olivergondza]

Ad #1: I am skeptical if this is actually needed/desired. There are lot more criteria to group the build besides the day such as SCM revision, version of sut/dependency, parameter value, build state, etc.

Ad #2: There is a tag for that: l:breakable. Btw, I have bad experience with inserting characters/entities into text as they break copy&paste/page search (#725 (comment)) but I am far from an expert in this field.

[tfennelly]

@olivergondza Thanks for the feedback.

Re point 1: I think it is definitely needed as there are a number of issues raised in JIRA already relating to build history text overflow, including (but not only) JENKINS-25381. Sure there are lots of other parameters by which you might want to group runs, but the reason for introducing the date separator is not particularly for the purpose of "grouping" (as you suggest). The point of introducing the separator is to remove all that date info from the run rows themselves and so reducing the amount of repetition and potential overflowing on each row etc. The fact that it results in a form of grouping is kinda secondary.

Re point 2: Thanks for flagging that. I'll look into it wrt the particular entity being used in this case.

[daniel-beck]

What does this look like for a regular old "nightly build" job with at most one build per day? Seems wasteful in that case.

While the date info is redundant, another option would be to make display name, date/time, and badges into three block elements that are wrapped as needed. Would something like the following be possible?

DN | Date Time | Ba.

---

Display Name | Date Time
Badges

---

Long Display Name
Date Time | Badges

---

Really really long display
name | Date Time
Extra many badges

The advantage here is that display names can be fairly long before they need to be broken.

[tfennelly]

@daniel-beck Thanks Daniel.

From what I know of html+css, getting those block elements to flow/wrap nicely could be a serious pain in the head. As well as that, I think it would complicate things in terms of what we'd need to do in terms of visual queues to clearly show where the blocks for one build stop and another start - atm it's clear that each run is on a line of its own. There's a UI/CSS guru in house at CloudBees. I'll ask him what we could do..

As for what does it look like when you have just one build per day...

[tfennelly]

Hmmm... build passes CI now :)

[tfennelly]

Based on what @daniel-beck suggests above, what if we did something like this ....

And then add the zero-space breaks to both the build and description to force them to overflow/wrap nicely.

[tfennelly]

Created another version of this on a branch called single-multi-line-buildhist. It's along the lines of what @daniel-beck suggested. It puts all build details on a single line so long as none of the fields in the row overflow. If any of them overflow, it converts the row to be "multi-line", where each field is changed into a block element (one field per line) and indented appropriately.

I also fixed it such that the left sidepanel is fixed width for screens wider than 768px.

See http://youtu.be/Uff078xcgrY

[tfennelly]

Closed this PR and replaced with #1470.

@saadi60pk can you please try the code on #1470 and see if it resolves your issue.