Managing the content of plugins.txt

Using Jenkins Ask a question
1

Hello all,
I run a dockerized jenkins (jenkins/jeknins). The plugins are installed from plugins.txt (where they are also versionned). So far I have only listed the plugins I chose to use, but not their dependencies.

The problem is that if I rebuild my jenkins image, “RUN jenkins-plugin-cli” is likely to error with “Multiple plugin prerequisites not met”. This is easy to fix, but it forces me to upgrade some plugins, which could yield problems. Also that made me realize that I cannot just pull an old commit and recreate the exact same jenkins from that commit (if it forces me to update some plugins).

The solution seems to be to have in plugins.txt the whole list of plugins including dependencies (list which I can get easily from the groovy console).

Would that be considered best practice?
I am slightly reluctant because keeping plugins.txt short, I knew what each plugin is doing and why it is there. But if I just have the whole list, and then want to remove a plugin, how will I know other dependencies plugins are not needed any more and should be removed?

It would be great to hear how others are using and managing the content of plugins.txt.

Thanks a lot
Mathieu

2

My first attempt with plugins.txt was to declare the subset that I thought was meaningful to me. After several bumps and bruises I found it was much easier to manage all the plugin names and versions in my plugins.txt file.

I have a few scripts that make the process easier for me, including

The update_plugins.py script attempts to create a single git commit for each plugin update so that it is easier for me to read the git log. It does not always work because there are times when multiple plugins need to be updated at the same time. It is helpful when it works. When it does not work, I use docker_build.py --report to tell me the commands I need to run in order to update the plugins.

3

I also have the same kind of problem/question… And we also have it in the GSoC project this year.

I have a script (heavily based on the infra team’s scripts 1 and 2 (thanks @smerle33 for the links) that deals with the total number of plugins installed, and not just the ones I’m interested in keeping.

4

Thanks both for your answers and code.
@MarkEWaite I can see that you are performing the actual update locally, into ref/plugins/, which is then copied by the dockerfile into the image.
What is the reason for this choice? (as opposed to updating locally plugins.txt only, and having the dockerfile copy plugins.txt and run jenkins-plugin-cli with it)
Thank you

5

I maintain the Jenkins git plugin and I needed an excuse to use GitHub’s large file support through Git LFS. Plugins look like large files, so I adopted that technique of updating both plugins.txt and the binary files. As far as I understand the preferred practice for most people is to create plugins.txt and assure that the container image they build runs the plugin installation manager tool when the container is created with docker build. My technique of keeping the binary files locally in my repository is not really useful for anyone but me.

Please don’t make the mistake of running the plugin installation manager tool when the container starts with docker run. That wastes startup time, wastes plugin delivery bandwidth, and risks that your container won’t start if the Jenkins update center is down.

6

I am not 100% sure what you mean. I run the plugins manager in the dockerfile. So unless plugins.txt has changed, the docker cache is used. Or was that the mistake you were talking about?

COPY plugins.txt /usr/share/jenkins/ref/plugins.txt
RUN jenkins-plugin-cli --plugins -f /usr/share/jenkins/ref/plugins.txt
7

We’ve seen cases where Kubernetes users were starting a Jenkins container. After that container started, they were adding plugins to the running container. That’s unhealthy.

The technique that you’re using is the right technique. Create the container with the desired plugins, then run the container that was created.

8

I am hitting an odd snag with the actual plugins update though.
I now can automatically create a new plugins.txt (with all the plugins, and new available version for a number of plugins). I re-launch my container to update my test instance of jenkins.

docker compose up -d --build

Then I see that the plug-ins have been updated to the new version, apart from 4 of them. I can update the 4 from the UI, but it seems strange that they did not update all using the plugins.txt.
jenkins version is: 2.375.2
The offending plugins are:

Command Agent Launcher Plugin (command-launcher):(1.2):100.v2f6722292ee8
JavaMail API (javax-mail-api):(1.6.2-5):1.6.2-9
JDK Tool Plugin (jdk-tool):(1.0):66.vd8fa_64ee91b_d
SSH server (sshd):(3.236.ved5e1b_cb_50b_2):3.303.vefc7119b_ec23

Does anybody has any idea of what could be causing this?
Thank you

9

I would guess that those plugins are not specified in your plugins.txt files, but are being loaded as dependencies of another plugin.

If they are specified in your plugins.txt file, then those are likely the versions specified in that file.

10

I’m running Jenkins in ECS (with EFS connected) - I’m noticing that removing a plugin from the plugins.txt file doesn’t uninstall it on the next deployment. What’s the best practice for removing installed packages in this instance?

11

To remove plugins via plugins.txt, we use entrypoint.sh to delete all the .jpi and .hpi files from /var/jenkins_home/plugins/.
That way Jenkins automatically reinstalls all the plugins from plugins.txt at every start of the container. Not claiming it is best practice, but I like the simplicity of it.

1 Like
12

That’s helpful! Thank you.