* [FIXED JENKINS-36476] Do not even send the default password in encrypted form; leave the text field blank, and apply the default upon submission.
* [JENKINS-36476] Use a special token, not the empty string, as the marker for the default value.
As far as I can figure, the /TcpSlaveAgentListener/ endpoint headers
tell the slaves what the JNLP port is. When I'm running jenkins behind a
proxy (marathon using the mesos plugin, which bridged networking), even
though I was setting the advertised port per a thread[1], it was not
accurately being returned in the header. This patch fixes that.
[1] https://groups.google.com/d/topic/jenkins-mesos/qUrXpDY07TQ/discussion
- 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
This reverts commit bb7c8fcedb.
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.
- 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.
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)
The test system I set up to verify resolution of customer(s)' issues driving this change, required
additional changes in order to fully resolve the issues at hand. As a result I am bundling these
changes:
- Moves nodes to being store in separate config files outside of the main config file (improves performance) [FIXED JENKINS-27562]
- Makes the Jenkins is loading screen not block on the extensions loading lock [FIXED JENKINS-27563]
- Removes race condition rendering the list of executors [FIXED JENKINS-27564] [FIXED JENKINS-15355]
- Tidy up the locks that were causing deadlocks with the once retention strategy in durable tasks [FIXED JENKINS-27476]
- Remove any requirement from Jenkins Core to lock on the Queue when rendering the Jenkins UI [FIXED-JENKINS-27566]
Set "X-UA-Compatible" meta tag (MSIE browsers only - forces browser compatibility mode)
JS based warning if Document Mode doesn't match IE version (MSIE browsers only)
Jesse Glick