- 16 7月, 2014 6 次提交
-
-
由 Jesse Glick 提交于
-
-
由 Jesse Glick 提交于
-
由 Daniel Beck 提交于
[JENKINS-2673] Clarify that suggestion means polling just once per hour
-
由 Jesse Glick 提交于
Correcting change made in #1176, which introduced an NPE, to restore original logic merely wrapped in a synchronized block. Reproduced NPE in new functional test (original bug probably very hard to reproduce).
-
由 Jesse Glick 提交于
-
- 15 7月, 2014 8 次提交
-
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
[JENKINS-14749] Suppress warnings about expected exception from prototype.js#HAS_EXTENDED_CREATE_ELEMENT_SYNTAX.
-
由 Jesse Glick 提交于
[JENKINS-14749] Temporarily work around CSS errors by just suppressing the warnings until they can be fixed.
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
The JNLP port is not interesting enough to warrant logging at INFO during every startup, including the vast majority of functional tests which do not even use JNLP slaves.
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
由 Jesse Glick 提交于
-
- 14 7月, 2014 9 次提交
-
-
由 tfennelly 提交于
-
由 tfennelly 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
由 Kohsuke Kawaguchi 提交于
-
- 13 7月, 2014 3 次提交
-
-
由 Fernando Boaglio 提交于
-
由 Daniel Beck 提交于
-
由 Daniel Beck 提交于
updated German translation
-
- 12 7月, 2014 13 次提交
-
-
由 Daniel Beck 提交于
-
由 Daniel Beck 提交于
-
由 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.
-
由 Kohsuke Kawaguchi 提交于
-
由 Daniel Beck 提交于
[FIXED JENKINS-17667] - Syncronization of InstallerTranslator::getToolHome()
-
由 Daniel Beck 提交于
Fix changelog generation in ExtractResourceWithChangesSCM
-
由 CloudBees DEV@Cloud 提交于
-
由 Daniel Beck 提交于
Break links inside pre tags
-
由 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 1 次提交
-
-
由 Jesse Glick 提交于
[JENKINS-22395] Taking advantage of BuildReference.clear (just introduced in b6226ad2) to simplify test by not requiring a custom build reference holder just to simulate GC. Confirmed that dropLinksAfterGC and dropLinksAfterGC2 both fail in the expected way (b1a.nextBuild == b2) after commenting out the call to createReference().clear() in dropLinks. (Also that they fail as expected in assertNotSame if the reference is not cleared at all.)
-