-
New Feature
-
Resolution: Fixed
-
Minor
-
None
-
Powered by SuggestiMate
For cases where JENKINS_HOME is located on e.g. NFS or a SAN, as the exploded plugin directories are really a redundant copy, it would be beneficial to be able to relocate these outside of JENKINS_HOME (much like the --webroot parameter allows relocating the extracted WAR file directory outside of JENKINS_HOME)
Most likely the only way to implement this is as either a system property or a CLI parameter as by the time Jenkins has started up it is too late to change the configuration option.
Additionally there is the use case where the JENKINS_HOME is on a redundant file system in case of disaster recovery, so the target extraction directory may vary depending on which node in the DR is being brought on-line, so it does not make sense to store this in a configuration file (as there is no guarantee that the mount paths are the same, etc)
[JENKINS-32765] Allow the directory that plugins are exploded into to be changed
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/Main.java
http://jenkins-ci.org/commit/extras-executable-war/7fb8540063d0b21ed4f78629cf9c8b2ed9960021
Log:
JENKINS-32765 Adapt to changed property name
See https://github.com/stephenc/jenkins/commit/c0cbff72972d7611da187f6258116e6b60d78e7d
Code changed in jenkins
User: Stephen Connolly
Path:
core/src/main/java/hudson/ClassicPluginStrategy.java
http://jenkins-ci.org/commit/jenkins/d27cff8fd2f500162368c265ab4d40808eb444da
Log:
[FIXED JENKINS-32765] Allow the directory that plugins are exploded into to be changed
- This really has to be controlled by either a system property or a CLI parameter as we cannot guarantee that any path
specified in a configuration file in JENKINS_HOME will be valid on another machine where the JENKINS_HOME is mounted - Obviously Jenkins does not currently support fully starting two Jenkins instances on the same JENKINS_HOME, so this
fix is to assist in Disaster Recovery (or semi-higher availability) sceanarios where the backup node is being brought
up. In such cases, the node that failed may not have correctly released all its file handles in the backing NFS share
and thus could be blocking the recovery node from starting up. - An additional use case is where the JENKINS_HOME is stored on a remote disk, e.g. a SAN, etc. and the user wants to
take advantage of the faster local disk to serve the resources from both plugins and Jenkins core. Without this change
only Jenkins core can be relocated outside of JENKINS_HOME (using the '--webroot=...' command line option). - Ideally we would introduce this into the extras-executable-war module once the system property has had time to soak
(although in an ideal world that module would be agnostic of Jenkins and thus it might not be appropriate there)
Code changed in jenkins
User: Stephen Connolly
Path:
core/src/main/java/hudson/ClassicPluginStrategy.java
core/src/main/java/hudson/PluginManager.java
http://jenkins-ci.org/commit/jenkins/c0cbff72972d7611da187f6258116e6b60d78e7d
Log:
JENKINS-32765 Perhaps it makes more sense to make this a property of the PluginManager rather than the classic strategy
- Also expose via servlet context parameter of same name to allow multiple instances of Jenkins in the same servlet container to have different directories
- As we are no longer a constant, change the system property to camelCase
Code changed in jenkins
User: Stephen Connolly
Path:
core/src/main/java/hudson/PluginManager.java
http://jenkins-ci.org/commit/jenkins/bdb3c0c6d5e368d3751b3c6dcac8863df217604a
Log:
JENKINS-32765 As I am not adding a new import, I will annotate with `@CheckForNull`
Of course the import being used is in a package name that is reserved for artifacts produced by a JSR... and the JSR that the dependency is claiming to come from has not actually published anything... thus whoever produced the artifact has broken the JSR policy... and it is also not safe for us to actually use these annotations as we do not know what a JSR may change on the road to actually providing this... but that is a war for a different PR
Code changed in jenkins
User: Stephen Connolly
Path:
core/src/main/java/hudson/PluginManager.java
http://jenkins-ci.org/commit/jenkins/566def3bd6e0d1f9fd8b0cd6f7e9600c95107780
Log:
JENKINS-32765 Fix failing tests
Code changed in jenkins
User: Stephen Connolly
Path:
core/src/main/java/hudson/ClassicPluginStrategy.java
core/src/main/java/hudson/PluginManager.java
http://jenkins-ci.org/commit/jenkins/c11e26504e3936c9ebe8306de5900645a1ab6fa6
Log:
Merge pull request #2012 from stephenc/jenkins-32765
[FIXED JENKINS-32765] Allow the directory that plugins are exploded into to be changed
Compare: https://github.com/jenkinsci/jenkins/compare/51f215c3b878...c11e26504e39
Integrated in jenkins_main_trunk #4444
[FIXED JENKINS-32765] Allow the directory that plugins are exploded (Revision d27cff8fd2f500162368c265ab4d40808eb444da)
JENKINS-32765 Perhaps it makes more sense to make this a property of (Revision c0cbff72972d7611da187f6258116e6b60d78e7d)
JENKINS-32765 As I am not adding a new import, I will annotate with (Revision bdb3c0c6d5e368d3751b3c6dcac8863df217604a)
JENKINS-32765 Fix failing tests (Revision 566def3bd6e0d1f9fd8b0cd6f7e9600c95107780)
Result = SUCCESS
stephen connolly : d27cff8fd2f500162368c265ab4d40808eb444da
Files :
- core/src/main/java/hudson/ClassicPluginStrategy.java
stephen connolly : c0cbff72972d7611da187f6258116e6b60d78e7d
Files :
- core/src/main/java/hudson/PluginManager.java
- core/src/main/java/hudson/ClassicPluginStrategy.java
stephen connolly : bdb3c0c6d5e368d3751b3c6dcac8863df217604a
Files :
- core/src/main/java/hudson/PluginManager.java
stephen connolly : 566def3bd6e0d1f9fd8b0cd6f7e9600c95107780
Files :
- core/src/main/java/hudson/PluginManager.java
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/Main.java
http://jenkins-ci.org/commit/extras-executable-war/ecf966c3f28fd8334e7cfa75422e36357316b579
Log:
Merge pull request #5 from jenkinsci/jenkins-32765
JENKINS-32765 Expose the exploded plugin archive directory as a command line option
Compare: https://github.com/jenkinsci/extras-executable-war/compare/ec617a6d41ba...ecf966c3f28f
Code changed in jenkins
User: Stephen Connolly
Path:
changelog.html
war/pom.xml
http://jenkins-ci.org/commit/jenkins/20317bb1e409d30626abf43f88bee07aa29524f3
Log:
JENKINS-32765 Update extras-executable-war to pick up system property and record feature in changelog
Integrated in jenkins_main_trunk #4449
JENKINS-32765 Update extras-executable-war to pick up system property (Revision 20317bb1e409d30626abf43f88bee07aa29524f3)
Result = SUCCESS
stephen connolly : 20317bb1e409d30626abf43f88bee07aa29524f3
Files :
- war/pom.xml
- changelog.html
Wouldn't it make more sense to introduce a single parameter "--cacheroot" (or something like that) where the webroot, the pluginroot and also the jar cache could be put (see JENKINS-18578), instead of providing an extra parameter for all of these?
That wouldn't work for people running in Bring-Your-Own-Servlet-Container mode, those people need a separate configurable option as the webapp expansion is controlled by e.g. Tomcat.
Additionally, when testing multiple versions of Jenkins it can be helpful to use different -webroot options with the same -pluginroot (assuming you have done the correct pinning)
Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/Main.java
http://jenkins-ci.org/commit/extras-executable-war/6fff1412cfc3a0d38a6834475857ace4f9d17969
Log:
JENKINS-32765Expose the exploded plugin archive directory as a command line option