Unclear behavior/documentation wrt cleaning plugin directory

[tnaroska]

Jenkins and plugins versions report

tested with: jenkins-plugin-manager-2.12.8.jar

Several inconsistencies and bugs regarding the cleaning of plugin directory.

1. the readme states for --plugin-download-directory that "The directory will be first deleted, then recreated". However this is not the case.
2. 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

[rrjjvv]

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.

[bendem]

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.

[bendem]

Fun, the flag looks like it was fixed in 2fd115e. Which was released in 2.12.9