- 21 7月, 2014 2 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 16 7月, 2014 1 次提交
-
-
由 Jesse Glick 提交于
-
- 14 7月, 2014 2 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 13 7月, 2014 1 次提交
-
-
由 Fernando Boaglio 提交于
-
- 12 7月, 2014 6 次提交
-
-
由 Kohsuke Kawaguchi 提交于
I think this is an oversight in bded790f. A random attacker wouldn't know the correct API token value, so given that it matched, I think the caller should know that it was the impersonation that failed, not the authentication. Also log this at a higher level, since this indicates a problem in SecurityRealm.
-
由 Jesse Glick 提交于
The actual implementation does not behave as nicely as one would hope, for a few reasons: 1. isEmpty actually tries to load the newestBuild, rather than simply checking whether there is some idOnDisk. Arguably this is necessary, since there could be an unloadable build record, in which case it would be technically correct for the map to be considered empty. 2. Loading AbstractLazyLoadRunMap.newestBuild calls search(MAX_VALUE, DESC), which behaves oddly, by doing a binary search, and thus perhaps loading lg(|map|) entries. You would think that it would suffice to check for the last member of idOnDisk in index.byId. 3. The iterator eagerly loads the next value before hasNext has even been called. Looks bad in a test, though it probably has little practical impact since most callers would be calling hasNext soon afterward anyway. Might cause one extra build record to be loaded unnecessarily from a limited RunList.
-
由 Jesse Glick 提交于
[JENKINS-18065] 54c08461 amendment: presumably RunMap.entrySet().iterator().next().setValue(…) should be illegal.
-
由 Jesse Glick 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kevin Burke 提交于
Now you can draw a straight vertical line and see that the logo image, the beginning breadcrumb, and the build history are all in a straight line.
-
- 11 7月, 2014 4 次提交
-
-
由 Kohsuke Kawaguchi 提交于
Just in case the previous fix didn't address the root cause of ZD-11985 (and given the time it takes for changes like this to land in LTS), I'm adding additional diagnostics that let us track how previous/next builds are getting discovered
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
Based on the last few commits, I proved that the original fix in f1430a25 doesn't really address the problem. That is, once b2 is deleted, and after sufficient garbage collection, we can make b2.previousBuild.get() be null, and then b2.getPreviousBuild().getNextBuild() ends up incorrectly returning b2. In this commit, I roll back that part of f1430a25, and then fix the problem differently. I started thinking that the main problem we are trying to fix here is that the deleted build object should be unreferenceable. That is, it should behave almost as if the object has already been GCed. The easiest way to do this is to clear a BuildReference object, since we always use the same BuildReference object for all inbound references. This change allows us to clear BuildReference. Code like b2.getPreviousBuild() will continue to try to update b1.nextBuildR to b2, but it will only end up wiping out the field, only to have b1.getNextBuild() recompute the correct value. This fix makes both test cases pass in LazyBuildMixInTest.
-
由 Kohsuke Kawaguchi 提交于
-
- 10 7月, 2014 1 次提交
-
-
由 Jesse Glick 提交于
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.
-
- 09 7月, 2014 1 次提交
-
-
由 Jesse Glick 提交于
WARNING: Caught exception evaluating: e.hasStopPermission() in /. Reason: java.lang.NullPointerException java.lang.NullPointerException at hudson.model.Executor.hasStopPermission(Executor.java:523)
-
- 08 7月, 2014 1 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
- 07 7月, 2014 4 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 tfennelly 提交于
-
- 04 7月, 2014 1 次提交
-
-
由 Daniel Beck 提交于
-
- 01 7月, 2014 1 次提交
-
-
由 Kanstantsin Shautsou 提交于
-
- 30 6月, 2014 4 次提交
-
-
由 Daniel Beck 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 28 6月, 2014 2 次提交
-
-
由 Daniel Beck 提交于
-
由 Kohsuke Kawaguchi 提交于
Reference: https://trello.com/c/doFFMdUm/46-filepath-getcomputer
-
- 26 6月, 2014 2 次提交
-
-
由 Oliver Gondža 提交于
-
由 Oliver Gondža 提交于
[FIXED JENKINS-23481][FIXED JENKINS-23551] Send onOffline notification to master computer prior Jenkins restart. Introduces new overload `ComputerListener.onOffline(Computer, OfflineCause)`.
-
- 25 6月, 2014 2 次提交
-
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 23 6月, 2014 3 次提交
-
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 22 6月, 2014 1 次提交
-
-
由 Daniel Beck 提交于
-
- 20 6月, 2014 1 次提交
-
-
由 nlabrot 提交于
-