You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several inconsistencies and bugs regarding the cleaning of plugin directory.
the readme states for --plugin-download-directory that "The directory will be first deleted, then recreated". However this is not the case.
there is an undocumented--clean-download-directory flag in the code here. However the implementation is broken. The directory contents is deleted. The directory itself is left in place. That by itself is not a problem. However the code then tries to re-create the plugin dir and fails with an "The plugin directory already exists" error.
At this point it is not even clear what the intended behavior is. The documentation and code are inconsistent. Having the clean-up behavior controlled by a cli-flag seems reasonable and gives most flexibility to users. If that is the goal, needed steps would be:
fix documentation of --plugin-download-directory flag.
add documentation for --clean-download-directory
fix implementation of --clean-download-directory to not error out if the directory exists.
What Operating System are you using (both controller, and any agents involved in the problem)?
all
Reproduction steps
Case 1:
mkdir plugins
touch plugins/xxx
# per documentation, this should delete and re-create 'plugins' directory
java -jar ../jenkins-plugin-manager.jar -d plugins --verbose --jenkins-version 2.277.4
ls plugins/xxx
Case 2:
mkdir plugins
# per documentation, this should delete and re-create 'plugins' directory
java -jar ../jenkins-plugin-manager.jar -d plugins --jenkins-version 2.277.4 --clean-download-directory
-> The plugin directory already exists: plugins
Expected Results
Case 1:
plugin directory is deleted and recreated as stated in the documentation or documentation needs to be adapted for the actual behavior
Case 2:
expect no "The plugin directory already exists: plugins" error
Actual Results
Case 1:
plugin directory is not deleted
Case 2:
command fails with "The plugin directory already exists: plugins"
Anything else?
No response
The text was updated successfully, but these errors were encountered:
The current behavior (not cleaning the directory despite the documentation's claim) works in my favor, in theory. Looking at the code, it appears that any plugins in the plugin directory are considered "installed", thus consulted to see if they satisfy other plugin dependencies, and presumably, have any missing dependencies installed as well.
My current use-case for pre-populating that directory involves a very simple plugin (it has no plugin dependencies, and likely does not satisfy any plugin dependencies), so I can't easily/quickly validate those assumptions. But I'm currently assuming it does (or could) work that way.
If the decision is made to honor the documentation (purging the existing directory), hopefully you'd consider making the equivalent of a --no-clean-download-directory option as well, to allow those pre-installed plugins to take part in the resolution process.
Changing the current behaviour to honour the documentation would be a breaking change. I'd be on the side of fixing the documentation and the --clean... flag.
Jenkins and plugins versions report
tested with: jenkins-plugin-manager-2.12.8.jar
Several inconsistencies and bugs regarding the cleaning of plugin directory.
--plugin-download-directory
that "The directory will be first deleted, then recreated". However this is not the case.--clean-download-directory
flag in the code here. However the implementation is broken. The directory contents is deleted. The directory itself is left in place. That by itself is not a problem. However the code then tries to re-create the plugin dir and fails with an "The plugin directory already exists" error.At this point it is not even clear what the intended behavior is. The documentation and code are inconsistent. Having the clean-up behavior controlled by a cli-flag seems reasonable and gives most flexibility to users. If that is the goal, needed steps would be:
--plugin-download-directory
flag.--clean-download-directory
What Operating System are you using (both controller, and any agents involved in the problem)?
all
Reproduction steps
Case 1:
Case 2:
Expected Results
Case 1:
plugin directory is deleted and recreated as stated in the documentation or documentation needs to be adapted for the actual behavior
Case 2:
expect no "The plugin directory already exists: plugins" error
Actual Results
Case 1:
plugin directory is not deleted
Case 2:
command fails with "The plugin directory already exists: plugins"
Anything else?
No response
The text was updated successfully, but these errors were encountered: