Jenkins plugins update

Using Jenkins Ask a question
1

Hi , I ran docker jenkins and tried to excute:
docker cp /your/path/to/plugins.txt <container_name>:/tmp/plugins.txt
docker exec -it <container_name> /bin/bash
jenkins-plugin-cli --plugin-file /tmp/plugins.txt --plugins delivery-pipeline-plugin:1.3.2 deployit-plugin
cp -r -p /usr/share/jenkins/ref/plugins/. /var/jenkins_home/plugins/.
exit as in GitHub - jenkinsci/plugin-installation-manager-tool: Plugin Manager CLI tool for Jenkins
,when I ran jenkins-plugin-cli --plugin-file /tmp/plugins.txt --plugins delivery-pipeline-plugin:1.3.2 deployit-plugin
. it showed to me the following msg:
Plugin configuration-as-code:1775.v810dc950b_514 unable to find dependant plugin json-api in update center https://updates.jenkins.io/update-center.actual.json

2

I’m not able to duplicate the problem based on your description.

Steps that I took while trying to duplicate the problem:

  1. Define the list of plugins that I use in a plugins.txt file. Since you didn’t include the definition of your plugins.txt file, I used mine
  2. Create a shell script that runs Jenkins 2.452.1 after downloading the files defined in my plugins.txt file and the delivery-pipeline-plugin:1.3.2 deployit-plugin plugins that you mentioned on your command line
  3. Run the shell script, confirm that Jenkins 2.452.1 starts as expected and that the plugins were loaded as expected

My plugins.txt file includes the most recent release of the configuration as code plugin, 1810.v9b_c30a_249a_4c, while yours must include 1775.v810dc950b_514 from 4 months ago since that is the version mentioned in the message. I’ve not attempted to duplicate your configuration with that older release of the configuration as code plugin. You’ll need to provide the contents of your plugins.txt file or update the versions in your plugins.txt file to the most recent releases.

The shell script that I used looks like this:

#!/bin/bash

# Jenkins plugin update fails with report that json-api cannot be found
#
# https://community.jenkins.io/t/jenkins-plugins-update/15469

JENKINS_WAR_VER=2.452.1
JENKINS_WAR=jenkins-${JENKINS_WAR_VER}.war
PLUGIN_MANAGER_VER=2.13.0
PLUGIN_MANAGER_JAR=jenkins-plugin-manager-${PLUGIN_MANAGER_VER}.jar

if [ ! -f ../$PLUGIN_MANAGER_JAR ]; then
  base=https://github.com/jenkinsci/plugin-installation-manager-tool/releases/download
  wget ${base}/${PLUGIN_MANAGER_VER}/$PLUGIN_MANAGER_JAR
  mv $PLUGIN_MANAGER_JAR ..
fi
if [ ! -d plugins ]; then
  mkdir plugins
fi
java -jar ../$PLUGIN_MANAGER_JAR \
     --jenkins-version $JENKINS_WAR_VER \
     --plugin-download-directory plugins \
     --plugin-file plugins.txt \
     --plugins delivery-pipeline-plugin:1.3.2 deployit-plugin

if [ ! -f ../$JENKINS_WAR ]; then
  base=https://get.jenkins.io/war-stable
  wget ${base}/${JENKINS_WAR_VER}/jenkins.war
  mv jenkins.war ../$JENKINS_WAR
fi

JENKINS_HOME=. java -jar ../$JENKINS_WAR

Other observations

Your script seems to be changing the plugins from inside the running container. That is not the preferred way to update plugins when using a container image. It is much more difficult to recreate the container and its plugin configuration when plugin updates are performed within the container.

Installing a 5 year old version of delivery pipeline plugin is surprising when there is a newer version that was released only 4 years ago.

3

ok thank you sir.
what about jenkins_war . I ran docker container jenkins where the jenkins_war directory is existed inside container at /usr/share/jenkins/jenkins.war

4

I assume you are asking if you should update the version of the Jenkins war file from inside the container. If that is your question, then the answer is “no”.

When the Jenkins project delivers a new Jenkins release, we also deliver a new tag for the container images that matches the release. Upgrades from one Jenkins version to the next are performed by changing the label of the container used in the FROM statement, not by replacing files inside an existing container image.

Many different examples are available of Dockerfiles using that pattern. For example:

5

thank u sir.
I use the following :
docker exec -it jenkins /bin/bash
cd /usr/share/jenkins
mv jenkins.war jenkins.war.old
wget https://updates.jenkins-ci.org/latest/jenkins.war

6

It is a mistake to replace the jenkins.war file inside the container image like that. That replacement technique makes it more difficult for you to manage the container in the future.

Container image definitions are usually tracked as code in a source code repository with a Dockerfile. When you update the Jenkins version inside a running container like that, you cause “configuration drift” where the Dockerfile that was used to create the container no longer represents the running container.

8

update Jenkins.war and plugins
when I launch Jenkins container , can I bind mount volume as :
volumes:

  • /usr/share/Jenkins/jenkins.war:/usr/share/Jenkins/jenkins.war
  • jenkins_home:/var/jenkins_home:rw # Workspace home
    then to update Jenkins container from outside use your code but update directory of Jenkins.war and plugin
update jenkins.war and plugins

#!/bin/bash

JENKINS_WAR_VER=2.452.1
JENKINS_WAR=/usr/share/Jenkins/jenkins-{JENKINS_WAR_VER}.war PLUGIN_MANAGER_VER=2.13.0 PLUGIN_MANAGER_JAR=jenkins-plugin-manager-{PLUGIN_MANAGER_VER}.jar

if [ ! -f …/PLUGIN_MANAGER_JAR ]; then base=https://github.com/jenkinsci/plugin-installation-manager-tool/releases/download wget {base}/${PLUGIN_MANAGER_VER}/$PLUGIN_MANAGER_JAR
mv $PLUGIN_MANAGER_JAR …
fi
if [ ! -d plugins ]; then
mkdir plugins
fi
java -jar …/$PLUGIN_MANAGER_JAR
–jenkins-version $JENKINS_WAR_VER
–plugin-download-directory /var/jenkins_home/plugins
–plugin-file plugins.txt
–plugins delivery-pipeline-plugin:1.3.2 deployit-plugin

if [ ! -f …/JENKINS_WAR ]; then base=https://get.jenkins.io/war-stable wget {base}/${JENKINS_WAR_VER}/jenkins.war
mv jenkins.war …/$JENKINS_WAR
fi

JENKINS_HOME=. java -jar …/$JENKINS_WA

9

The idea of the docker container is that it is fixed with respect to jenkins version and installed plugins. So in case you want to update jenkins and/or plugins you create a new docker image.
With your approach a docker container is not required at all.

10

you mean that I can’t update container

11

Why have a container just to replace the things are a burnt into the image at startup?
So you can do it in the way you do it right now, but you don’t need a docker container for this. It might be easier to understand what is going on when you do it without a container.

12

ok , what about the Image I have or downloaded from docker hub is need to update , and there is no recent releases of that image

13

Choose a base container image that is being updated regularly. If the base container image you are using is not regularly updated, then it is time to change to an image that is updated regularly.

14

Ok thank you Sir . what is the suitable image jenkins for continous integrration

15

The Jenkins installation instructions for Docker and the Jenkins tutorials that are based on Docker (Apache Maven, React and NodeJS, and Python) all use the jenkins/jenkins container image on DockerHub.

The dependabot tool from GitHub can be configured to periodically propose pull requests to update the container version in a GitHub repository. That reduces the overhead of managing container versions. Examples are available in the Jenkins docker repository.

16

thank u sir, but there is no caching for image layers when Rebuilding an image using jenkins/jenkins container through continous integration , I need to build image from jenkins or (GitHub - jenkinsci/blueocean-plugin: Blue Ocean is a reboot of the Jenkins CI/CD User Experience) . then launching a container jenkins for continous integration

17

That sounds like a problem in the environment where you are building containers. You’ll want to fix that problem, not avoid the problem by taking full responsibility for the entire definition of the container image.

If you truly must build a container image from the Jenkins war file, then you should refer to the Dockerfile definitions in the GItHub repository where the Jenkins project stores the container definitions for Jenkins controllers. That repository contains the results of years of learning about container builds and container maintenance.

I think it is unwise to recreate something at a lower level (build a container from the Jenkins war file) when you can reuse something that is already defined at a higher level (container that already includes the Jenkins war file, includes plugin management facilities, includes support for configuration as code, and more).

1 Like
18

Ok thank you sir for your clarification, do you mean that jenkins/jenkins container is able to cache the builded image layers when you need to use caching for rebuilding that image

19

Caching image layers is a task of the docker command that builds the container image. It is not something that the container definition controls. If your CI environment does not cache image layers, that is something to fix in your CI environment.

20

jenkinsci/blueocean is adjusted to access docker binary and it can cache when rebuilding docker images and there are many additions to official jenkins/jenkins , and these additions require experience

21

The jenkinsci/blueocean container image is no longer maintained. It has not been updated in over two years. It uses an end of life Alpine 3.16.2 operating system as its base image and includes Jenkins version 2.346.3 with known critical security vulnerabilities. It only supports amd64 platforms.

The jenkins/jenkins container image is actively maintained. It uses current operating system versions as its base. It can be configured to have all the features that were available in the jenkinsci/blueocean container image plus many more. It supports amd64, aarch64, s390x, and ppc64le platforms.