- 27 3月, 2015 7 次提交
-
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
- JENKINS-15355 - JENKINS-21618 - JENKINS-22941 - JENKINS-25938 - JENKINS-26391 - JENKINS-26900 - JENKINS-27476 - JENKINS-27563 - JENKINS-27564 - JENKINS-27565 - JENKINS-27566 - Fixing link text for JENKINS-6167
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
-
-
由 Jesse Glick 提交于
Remove editorconfig
-
由 Jesse Glick 提交于
simplify displaying the executors
-
- 26 3月, 2015 26 次提交
-
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
fix the @since tags
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
[JENKINS-27565] Fix threading issues with Nodes and Queue
-
由 Oliver Gondža 提交于
-
由 Stephen Connolly 提交于
-
由 Oliver Gondža 提交于
-
由 Jesse Glick 提交于
-
由 Stephen Connolly 提交于
Ensure that listeners do not get notified when a computer is killed from a thread with the Queue lock - We don't know what those listeners will be doing - I'm not completely happy with having to do it this way, there are some theoretical paths where we end up re-acquiring the Queue lock in Computer.kill() but they should not be the normal path
-
由 Stephen Connolly 提交于
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
API improvements around Executor/Executable
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
由 Stephen Connolly 提交于
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
Additional change suggestions on top of PR 1610
-
由 Kohsuke Kawaguchi 提交于
IIUC, the expectation here is that Queue.Executable will instantiate AsynchronousException as a handle, start something asynchronously (say send a JMS message) with a callback, and the callback will tickle AsynchronousException. So AsynchronousException might complete before it gets its executor set. This code change ensures that that case gets handled correctly.
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 25 3月, 2015 7 次提交
-
-
由 Stephen Connolly 提交于
Update the retention strategies... the JSR 305 annotations do not seem to be spec'd to apply to child methods also... bold poorly spec'd annotations
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
Remove `jenkins.setNodes(jenkins.getNodes())` style hacks to force the master number of executors to be updated
-
由 Stephen Connolly 提交于
-
由 Stephen Connolly 提交于
- We will never mind that this is probably the wrong import to use as Jenkins core is consistently using the wrong one (If anyone asks, for a `javax` import to be correct, it should have a JSR that has passed through voting and not have a JSR that is still subject to change... OTOH one could argue that if the JSR 305 should ever become revived from its current dormant state *and* it is decided to include in the JRE *then* the packages would get moved out of `javax` and into `java` so they are not in final form anyway... but that pre-supposes that the process of standardization does not modify the annotations and by virtue of being in `javax` there will be some special case handling by some classloaders which is why depending on the JSR305 versions is, in my view, a bad plan... anyway this is moot... Jenkins core is going with JSR305 as it currently stands so we call all go down together!)
-