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.

[JENKINS-25691] Might have prevented the need for: https://github.com/jenkinsci/maven-plugin/pull/33

ssh-slaves plugin can leverage this to try to obtain the state of the slave JVM via SSH.

Reference: ZD-23093

Reference: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8051847
Reference: ZD-23093

Reference: ZD-23093

Caused a failure in hudson.plugins.promoted_builds.conditions.ManualConditionTest.testManualPromotionProcessViaWebClient when run against 1.580.1.

Allow Projects to take the Queue.Item's actions into consideration when determining their default authentication

- 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 "it.value" don't exist, so we need to set the defaultParameterValue. 

It help me display correctly parameter for my multilauncher plugin. 
Note that other ParameterDefinition use the default value to display parameter, so IMO it is safe to do this.

AtomicFileWriter.commit should use Util.deleteFile so as to get a more meaningful error message in case the deletion fails.
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 …

The use case that led me here was to use this from workflow which relies primarily on Java serialization

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.

return authentication object instead of null if authentication is not
required - otherwise valid login fails with basic authentication

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: NOleg Nenashev <o.v.nenashev@gmail.com>

[JENKINS-2786] Makes no sense for Computer.currentComputer to return MasterComputer when not on an executor thread.

This matches fb65a2c3c8584a9ac4daa49ecbce7a540dc7f5a5 in remoting.