Jenkins docker issue: Multiple plugin prerequisites not met

Using Jenkins Ask a question
5

My experience has been that I need to specify the precise version of all the plugins, otherwise the dependency resolution process in the plugin installation manager tool will install versions that I don’t recognize. Your yaml file seems to specify a few key plugins and then relies on the dependency management system to resolve the other dependencies.

I created a plugins.txt for the current installation with the script from the “How to report an issue” page. That script looks like this (run from in the Jenkins script console):

Jenkins.instance.pluginManager.plugins
    .collect()
    .sort { it.getShortName() }
    .each {
        plugin -> println("${plugin.getShortName()}:${plugin.getVersion()}")
    }
return

Once that is stored as plugins.txt, then I use the following command to periodically check for updates to the plugins as defined in the plugins.txt file.

$ ./jenkins-plugin-cli.sh --jenkins-version 2.319.3 \
  --plugin-download-directory ref/plugins \
  --plugin-file plugins.txt \
  --no-download \
  --available-updates \
  --output txt > x && mv x plugins.txt
$ ./jenkins-plugin-cli.sh --jenkins-version 2.319.3 \
  --plugin-download-directory ref/plugins \
   --plugin-file plugins.txt

That sequence of commands first checks for available updates and prepares a new plugins.txt file, then downloads the plugins to match the new plugins.txt file. I’ve preferred to store my plugin binary files and the plugins.txt file as large files in a Git repository. I did that because I needed an excuse to use large file storage. I don’t know that is the best solution, but it let me learn more about git LFS.

If you’d like to see the public part of that setup, see

That repository contains multiple Docker image definitions so that I can quickly switch from one testing setup to another testing setup. There is another repository that tracks private content using the same concepts.

1 Like