[FIXED JENKINS-23683] Check whether war's directory is writable
New general layout using <div>s
Merge pull request #1294 from jenkinsci/pull/1265/head

[FIXED JENKINS-23294] Interpret X-Forwarded-Port
Merge pull request #1253 from daniel-beck/ModelHyperlinkNote-MasterNode

Return correct URL to Jenkins master node
Merge pull request #1311 from daniel-beck/JENKINS-23683

[FIXED JENKINS-23683] Check whether war's directory is writable
Suppressing NPE from SaveableListener.all during shutdown.
https://gist.githubusercontent.com/vivek/0d4d153cd9faad6e5743/raw/78a1d1b317894360c2ca06c7f4469f694ca7d573/gistfile1.java
[maven-release-plugin] prepare release jenkins-1.571
[maven-release-plugin] prepare for next development iteration
updated changelog for release
updated changelog as a part of the release
merged back the RC branch
creating an RC branch
the trunk is toward 1.573-SNAPSHOT
Failed to diagnose an NPE in 1.554.3.
WARNING: Caught exception evaluating: e.hasStopPermission() in /. Reason: java.lang.NullPointerException
java.lang.NullPointerException
	at hudson.model.Executor.hasStopPermission(Executor.java:523)
Undeprecating Job.getBuild, since this is the only way to look up a build by ID if you are unsure what kind of Job it is.
Switch underline/non underline on sidebar

The underline adds slightly too much visual weight to the links in question.
This changes the links to not have an underline by default, while still adding
the underline when the link is hovered.

Normally accessibility requirements demand that you add an underline for all
clickable text. However, in this case the positioning of the elements, their
changed color, the presence of an icon next to the links, and the link hover
effect combine to give these elements the appearance of clickability.
Noting #1310, #1294, #1311
Merge pull request #1314 from kevinburke/lighter

Switch underline/non underline on sidebar
update to #index must be synchronized
[JENKINS-22395]

I'm not sure if I understand how the original fix in PR #1190 (f1430a2) addresses the problem.

My understanding is of the problem is as follows:

  - someone deletes 'b2' but holds on to its reference (could be different threads)
  - someone calls b2.getPreviousBuild()
    - if b2.previousBuildR is null, then this triggers the loading of b1, and
      that process sets up a bi-di link via b1<->b2 via b1.nextBuildR <-> b2.previousBuildR
    - this makes b1.getNextBuild() incorrectly return b2

Presumably f1430a2 addresses this somehow, but I think I can induce this situation in other ways,
which is what dropLinksAfterGC2() does.

In this test,

initial state:

   b1 <-> b2 <-> b3

   we load everyone and connect them all up

after deleting b2:

   b1 <--------> b3
    ^            ^
    +---- b2 ----+

  b1 and b3 points each other, and b2 still refers to each side

after dropping b1:

          b2 --> b3

now, here, when I do b2.getPreviousBuild(), it loads b1a and it sets b1a.nextBuildR to b2.

    b1a <-> b2 --> b3

So I claim this is a proof that the fix is incomplete, even for the problem JENKINS-22395 has discovered.

I don't think that the problem is for the dropLinks call to fail to patch up references.
The problem is that b2.getPreviousBuild() forcing b1 to point to b2, because if b2 is deleted and assumed to be
invalid, then no matter what bX this method will find you never want bX.nextBuildR to point to b2.