Not fully solved, since the scannedDirs field can still grow to be large, but at least clearing files/dirsNotIncluded.
Also imposing a 5s timeout on the scan regardless of file count, and defining a user-customizable bound.
- Also tidy up some holes in locking strategy that can cause builds to be scheduled on
executors that are about to be interrupted or nodes in the process of being removed
The following is not helpful in terms of diagnosing the root problem:
java.io.IOException: Unable to delete /…/jobs/demo/builds/…/workflow/3.xml
at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:112)
at hudson.XmlFile.write(XmlFile.java:179)
at org.jenkinsci.plugins.workflow.support.storage.SimpleXStreamFlowNodeStorage.saveActions(SimpleXStreamFlowNodeStorage.java:106)
at …
IIUC, the issue here is that the request in question contains both a
valid session cookie AND basic authentication header, and that path
results in a failure because BasicHeaderProcessor expects one of
BasicHeaderAuthenticators to validate the basic authentication header
(without knowing that there's already a valid Authentication object that
came from the HTTP session, yet no BasicHeaderAuthenticator actually
processes this because BasicHeaderRealPasswordAuthenticator backs away
from doing that.
I think the corect fix is for BasicHeaderRealPasswordAuthenticator to
get rid of authenticationIsRequired check. This check instead belongs to
BasicHeaderProcessor, where it should be used to check if any
BasicHeaderAuthenticator should be consulted or not.
The problem with having this logic in
BasicHeaderRealPasswordAuthenticator is that this is just an
implementation of an extension point, and thus it needs to be removable.
As it stands right now in this fix, if this impl is removed,
JENKINS-25144 will be back again.
jenkins.model.Jenkins::getInstance() method is marked as @CheckForNull, but the most of Jenkins code does not actually check the return value. It leads to tons of static analysis errors, hence it is hard to analyze the code.
The change also adds annotations to old methods like Hudson::getInstance()
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
Even though SezpozModule.configure catches and ignores the faulty component, Guice still dies:
… hudson.ExtensionFinder$GuiceFinder <init>
SEVERE: Failed to create Guice container from all the plugins
com.google.inject.internal.guava.collect.$ComputationException: java.lang.NoClassDefFoundError: org/eclipse/jgit/storage/file/FileRepository
at …
at com.google.inject.Guice.createInjector(Guice.java:73)
at hudson.ExtensionFinder$GuiceFinder.<init>(ExtensionFinder.java:279)
Jesse Glick