* Slave.JnlpJar.getURL did not work in some modes when core had a snapshot dependency on Remoting.
* Starting to implement Channel.Listener.read/write.
* Now obtaining response timing statistics.
* For now, avoiding timestamped snapshots, as it caused problems for #3120 which I have asked for help from @stephenc diagnosing.
* Simplified logging a bit.
* onResponse
* hudson.FilePath$Mkdirs is a lot more readable than hudson.FilePath$13.
* Specific snapshot.
* onJar
* LoggingChannelListener
* remoting.version=3.17
* Making a few test assertions more lenient to adapt to https://github.com/jenkinsci/remoting/pull/247.
* Use "Files.createTempDirectory" to create temp directory instead
See SonarQube critical vulnerability squid:S2976 (tag: owasp-a9)
https://next.sonarqube.com/sonarqube/coding_rules#rule_key=squid%3AS2976
* [JENKINS-48227]
Creating a utility "static Path toPath(File file) throws IOException" method,
which wraps InvalidPathException to IOException so that it will be checked.
- also fixed public static final reference
- fixed broken test cases
- added new test cases for toPath() and createTempDir()
* Revert back to public static int
* adjustments due to merges
* Add posix check to determine if Posix FileAttributes should be included
in call to Files.createTempDirectory()
* Remove reference to private element
* Updated to use explicit imports
* Move an instance of renameTo() to Files.move()
* Replace an instance of File.toURI() with an instance of Path.toUri()
* Replace mkdirs() with Files.createDirectories()
Replace mkdir() with Files.createTempDirectory()
* Undo addition of createTempDirectory() as per review comments
* Return to use of FilePath#mkdirs(File) and instead modify it to use the new API.
* Undo addition of toPath() in a URI conversion as it brings no benefits.
* Replace new uses of toPath() with Util.fileToPath() to pre-handle runtime exceptions
* Remove * import.
move mkdirs() to using FilePath method instead of File method.
* Make IOUtils.mkdirs(File) use Java7 API calls
* Add back accidentally removed imports.
* Fixed use of wildcard import
* Use utility method fileToPath() to handle potential exception thrown
* Use NIO for FilePath#chmod and IOUtils#mode
* Add tests for NIO mode and chmod implementations
* Add test, remove new method, and update JavaDoc
* Provide system property to use native implementations of chmod and mode
* Revert unrelated whitespace modification
* Don't remove exception from throws and put imports in original location
* Fix broken JavaDoc links
* Ignore file type bits (above 0o7777) in Util#modeToPermission
* Use octal for constants and don't include file type bits
* Revert unnecessary changes to TarArchiverTest
* Add assertion that non-permission bits are ignored by chmod
* Use NIO copy with StandardCopyOption.COPY_ATTRIBUTES in copyToWithPermissions where possible
* Catch InvalidPathException and convert it to IOException
* Create utility method for File#toPath and use File#createDirectories after review
* Remove useless calls to toAbsolutePath and getAbsoluteFile
* Fix typos and use octal for constant after review
* Add test for behavior of copyToWithPermission with special bits
mkdirs do remoting call by creating anonymous class.
Remoting on remote side must load outer FilePath class with imports.
FilePath had SystemProperties OnMaster.
* Annotate and document methods of hudson.Launcher
* Fix newly introduced FindBugs issues in hudson.Launcher
* Remove brackets from FilePath#createLauncher() to avoid the merge conflict
* Clean up usages of IOUtils.closeQuietly and related calls predating Java 7.
* Review comments from @oleg-nenashev.
* Noticed another place where try-with-resources would protect against a potential leak.
- 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)
In addition to cluttering the namespace, unused imports generate
compiler warnings, introducing noise and obscuring more important
compiler warnings. This change removes them.
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.
Daniel Beck