Jenkins docker issue: Multiple plugin prerequisites not met

I get this error with this Dockerfile for jenkins-rest that used to work not so long ago:

Sending build context to Docker daemon   7.68kB
Step 1/6 : ARG jenkins_tag=2.277.4-jdk11
Step 2/6 : FROM jenkins/jenkins:$jenkins_tag
 ---> 9d90b56f1a78
Step 3/6 : COPY --chown=jenkins:jenkins init.groovy.d/ /usr/share/jenkins/ref/init.groovy.d/
 ---> d3cb7ae342be
Step 4/6 : COPY --chown=jenkins:jenkins plugins.yml /usr/share/jenkins/ref/plugins.yml
 ---> 432d6654a0be
Step 5/6 : RUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.yml
 ---> Running in 6314274b56fe
Multiple plugin prerequisites not met:
Plugin workflow-aggregator:2.6 depends on cloudbees-folder:6.708.ve61636eb_65a_5, but there is an older version defined on the top level - cloudbees-folder:6.17Multiple plugin prerequisites not met:

I am not sure what is going on but I was expecting this to be stable and not try to use latest versions. Is there anything I can do to fix it?

I know @MarkEWaite has a good response for this. I believe it has to do with specifying versions sometimes but not others? :crossed_fingers:

I tried changing step 6 to the old install-plugins.sh script, but it too fails:

Step 5/6 : RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/ref/plugins.yml
 ---> Running in 43a5eb008617
WARN: install-plugins.sh is deprecated, please switch to jenkins-plugin-cli
Creating initial locks...
mkdir: cannot create directory ‘/usr/share/jenkins/ref/plugins/- artifactId.lock’: File exists

I’ll try upgrading the jenkins_tag.

It does work with 2.335-jdk11. So there was a turning point that I missed I guess.

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