Seems to have caused spurious timeout errors.
https://jenkins.ci.cloudbees.com/job/core/job/jenkins_main_trunk/1748/testReport/junit/hudson.scheduler/CronTabEventualityTest/testFirstSundayOfMonthWillBeEventuallyTriggeredWithinOneMonthAndOneWeek_0_/
java.lang.Exception: test timed out after 1000 milliseconds
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.exists(File.java:772)
at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:1072)
at sun.misc.URLClassPath.getResource(URLClassPath.java:199)
at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at hudson.scheduler.CronTab.set(CronTab.java:87)
at hudson.scheduler.CronTab.<init>(CronTab.java:83)
at hudson.scheduler.CronTab.<init>(CronTab.java:66)
at hudson.scheduler.CronTabEventualityTest.checkEventuality(CronTabEventualityTest.java:113)
at hudson.scheduler.CronTabEventualityTest.testFirstSundayOfMonthWillBeEventuallyTriggeredWithinOneMonthAndOneWeek(CronTabEventualityTest.java:109)
Instead it was being thrown in a Future that the master did not wait for:
the writing side failed with a closed pipe exception, and this meaningless error was thrown up.
Fixing by waiting for the reading side first, so any error there will be thrown up.
(If there was _also_ an error on the writing side, we would miss it, but typically this will just be the closed stream.)
Added a unit test (and supporting localExpiredBuilder) to expose a
defect in the search() method of AbstractLazyLoadRunMap whereby the
index contained an entry for the requested build number, but the
BuildReference's referent was null.
Fixed the search() method to handle this rare[ish] corner case.
Given these <variable,value> mappings: <A,a> and <A.B,a-b>, $A.B would
evaluate to $a.B, as it currently does, and ${A.B} to a-b instead of the
current ${A.B}.
Existing ${A.B}-like references will break (not evaluate to ${A.B}) if
there actually is an A.B variable defined, which I think is very
unlikely.