- 01 8月, 2016 1 次提交
-
-
由 Oleg Nenashev 提交于
Queue.ItemList: Be sure we cleanup the list instead of the entire Queue (IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD)
-
- 08 7月, 2016 1 次提交
-
-
由 Jesse Glick 提交于
[FIXED JENKINS-27530] Jenkins.reload must also reload the Queue to ensure that every Queue.Item.task corresponds to a live Job, lest nextBuildNumber be bogus.
-
- 03 6月, 2016 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
getItem() and contains() act exactly the same
-
- 16 5月, 2016 1 次提交
-
-
由 Oliver Gondža 提交于
-
- 09 3月, 2016 2 次提交
-
-
由 Stephen Connolly 提交于
- Code that is running from a plugin and on the master's JVM is guaranteed to never get null from this method (any cases where you do get null are bugs in core) - Code that is running from a plugin and on a remote JVM should never be allowed to load the Jenkins class in their classloader, so should never use Jenkins.getInstance()... we are annotating the method with @Nullable so that such code can have some evolution time - Code that is running in core and on one of two special paths should use the Jenkins.getInstanceOrNull() method so that the UI can be presented to users before the singleton has been instantiated / after the singleton has been destroyed - The remaining 95% of uses in core (and 100% of uses in plugins) can safely assume that the instance is never null
-
由 Stephen Connolly 提交于
This reverts commit bb7c8fce. Closes #2090, I'll redo this as a PR... though if that PR is subject to multiple rounds of review before being merged then I will take that of evidence of the exact problem that committing directly was supposed to resolve... namely exponentially multiplying the effort required to make actual improvements to the code base.
-
- 08 3月, 2016 2 次提交
-
-
由 Stephen Connolly 提交于
- Plugins using these methods will be safe - The code path I need to analyse is the `Jenkins.super()` constructor code path. As Jenkins extends AbstractCIBase if there is a call there that requires the queue lock during construction it may require these methods to be safe against being called before the singleton has been put in place
-
由 Stephen Connolly 提交于
- It is never too late to do the right thing. - The vast majority of usages of `Jenkins.getInstance()` in core currently assume that its return value is non-null - This commit changes those that are written to correctly check for non-null values will call `Jenkins.getInstanceOrNull()` - We deprecate the `Jenkins.getActiveInstance()` madness - I checked with @kohsuke who said not to bother with a PR and just commit this strongly opinionated change direct to master as a PR will just degrade into a bikeshedding.
-
- 07 3月, 2016 1 次提交
-
-
由 Ing. Pavel Janousek 提交于
clear-queue covered by test-cases
-
- 30 1月, 2016 1 次提交
-
-
由 Antonio Muñiz 提交于
-
- 29 1月, 2016 1 次提交
-
-
由 Andres Rodriguez 提交于
Now that the item list is obtained lock-free the cache is no longer needed. Besides, the cache could be returning invalid results for requests with different authorization to the one that cached the result (in any case this invalid result is transient).
-
- 26 11月, 2015 1 次提交
-
-
由 Stephen Connolly 提交于
- The previous check was to narrow. - We now check on AccessControlled (which is implemented by Item) - We now also check on Permission.READ (which is the generic read permission) This should allow subtasks who's task may not be an Item to at least implement AccessControlled to alow visibility. There remains an open question as to whether tasks that are not AccessControlled should ever be visible in the UI (cherry picked from commit cf1fdf98)
-
- 25 11月, 2015 1 次提交
-
-
由 Stephen Connolly 提交于
-
- 19 11月, 2015 2 次提交
-
-
由 Stephen Connolly 提交于
- The previous check was to narrow. - We now check on AccessControlled (which is implemented by Item) - We now also check on Permission.READ (which is the generic read permission) This should allow subtasks who's task may not be an Item to at least implement AccessControlled to alow visibility. There remains an open question as to whether tasks that are not AccessControlled should ever be visible in the UI
-
由 Johannes Ernst 提交于
* moved to jenkins.util.SystemProperties * consistent naming getString/getInteger/getBoolean * improved code formatting Improved JavaDoc
-
- 17 11月, 2015 1 次提交
-
-
由 Johannes Ernst 提交于
Accomplished by centralizing calls to System.getProperty(String) and related into new file SystemProperties.java. There, we first check for existence of system property; if not, we look for property in context.xml This is done for "application" properties (like hudson.DNSMultiCast.disabled) but not for java properties (like user.name)
-
- 10 11月, 2015 1 次提交
-
-
由 Christopher Simons 提交于
In addition to cluttering the namespace, unused imports generate compiler warnings, introducing noise and obscuring more important compiler warnings. This change removes them.
-
- 28 10月, 2015 1 次提交
-
-
由 Stephen Connolly 提交于
[FIXED JENKINS-30084] FlyWeightTasks tied to a label will not cause node provisioning and will be blocked forever. When a flyweighttask is limited to run on a specific label (e.g. matrix project set restrict where this project can run) if there are no nodes with that label available when it enters the queue then it will immediately move to blocked. As it is blocked the Node provisioner will not attempt to create any slaves, so the project will sit in the queue forever (or until some other project allocates a slave with the correct label). (cherry picked from commit 5a5f9c5d)
-
- 13 10月, 2015 2 次提交
-
-
由 Valentina Armenise 提交于
-
由 christ66 提交于
-
- 12 10月, 2015 4 次提交
- 02 10月, 2015 16 次提交
-
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-
由 Valentina Armenise 提交于
-