- 23 7月, 2013 3 次提交
-
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
- 22 7月, 2013 4 次提交
-
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
- 21 7月, 2013 7 次提交
-
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
- 20 7月, 2013 8 次提交
-
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
- 19 7月, 2013 2 次提交
-
-
由 Olivier Lamy 提交于
-
由 Olivier Lamy 提交于
-
- 15 7月, 2013 2 次提交
-
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
[JENKINS-3265] [JENKINS-17341] Even if older plugins throw an NPE during reload, continue loading job.
-
- 14 7月, 2013 6 次提交
-
-
由 Christoph Kutzinski 提交于
-
由 Christoph Kutzinski 提交于
removed the noAnime() conversions, so we can rely on the compiler to warn us, if we forget a case here
-
由 Christoph Kutzinski 提交于
-
由 Christoph Kutzinski 提交于
-
由 Christoph Kutzinski 提交于
-
由 Christoph Kutzinski 提交于
Add convenience method for checking if object is MatrixProject
-
- 13 7月, 2013 2 次提交
-
-
由 Christoph Kutzinski 提交于
-
由 Christoph Kutzinski 提交于
-
- 12 7月, 2013 4 次提交
-
-
由 Christoph Kutzinski 提交于
[FIXED JENKINS-18671] Clock Difference broken on Manage Nodes page
-
由 Jesse Glick 提交于
-
由 Richard Mortimer 提交于
-
由 Richard Mortimer 提交于
against incorrect values if times are ever compared between different JVM nodes
-
- 11 7月, 2013 1 次提交
-
-
由 Richard Mortimer 提交于
System.nanos() returns a monotonically increasing value that is not related to wallclock time. Use System.currentTimeMillis() instead.
-
- 10 7月, 2013 1 次提交
-
-
由 Jesse Glick 提交于
Unlike the bug I originally reproduced, in which the parent had some builds but the context in which the new build was scheduled omits a parent, this seems to be due to a case in which there is no build record at all for the parent. No idea how that could happen (getLastBuild should return even a running, failed, or aborted build), but @treydock reports a stack trace in 1.509.2 which implies this. So fixing null safety; will not prevent an exception but will report it more gracefully.
-