Jenkins docker issue: Multiple plugin prerequisites not met

Using Jenkins Ask a question
1

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?

2

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

3

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.

4

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

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