Keep the plugin list up to date when building the Docker image

[gounthar]

For the time being, we're calling RUN jenkins-plugin-cli --plugin-file /usr/share/jenkins/ref/plugins.txt when building the image.
What about adding options, so we get an updated list of plugins before installing them?

jenkins-plugin-cli --plugin-file /usr/share/jenkins/plugins.txt --no-download --available-updates --output txt

That would give something like:

FROM jenkins/jenkins:2.401.1-lts
USER jenkins
RUN echo "2.0" > /usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state

# Copy the plugins.txt file into the Docker image
COPY plugins.txt /usr/share/jenkins/ref/plugins.txt

# Update the plugins.txt file with the latest available versions
RUN jenkins-plugin-cli --plugin-file /usr/share/jenkins/ref/plugins.txt --no-download --available-updates --output txt > /tmp/updated-plugins.txt && mv /tmp/updated-plugins.txt /usr/share/jenkins/ref/plugins.txt

# Install the updated plugins
RUN jenkins-plugin-cli --plugin-file /usr/share/jenkins/ref/plugins.txt


COPY jenkins.yaml /var/jenkins_home/casc_configs/jenkins.yaml
ENV CASC_JENKINS_CONFIG /var/jenkins_home/casc_configs/jenkins.yaml

@ash-sxn @berviantoleo @jmMeessen what do you think about that?

[ash-sxn]

So In the future, if anything breaks because of an update in the plugins, We'll be able to track back which plugin was last updated and broke things, right?

[gounthar]

I'm not so sure that's the case unless we commit and push as soon as the plugin list changes...
To me, that's a kind of (nice) band-aid until we get something like updatecli to take care of the updates.

[ash-sxn]

Okaay, I understand now

[berviantoleo]

What about adding options, so we get an updated list of plugins before installing them?

I disagree with this a bit. I think it will introduce some breaking plugins. Except, if updated to a minor version. Am I right?

Or, do you recommend taking the plugins.txt after building the image?

[gounthar]

You can always introduce breaking changes when updating plugins without thoroughly reviewing the changelogs.
I personally prefer to have up-to-date plugins, even if there's a risk of something breaking, rather than using outdated plugins with potential vulnerabilities.

I understand that this is a matter of preference and open to discussion.

The infra team does it this way:
https://github.com/jenkins-infra/docker-jenkins-lts/actions/runs/5354939180/workflow
https://github.com/jenkins-infra/docker-jenkins-lts/blob/main/bin/update-plugins.sh

[gounthar]

@MarkEWaite proposed an up-to-date plugin list for the second example in #96.
He also proposed two scripts, one in bash and one in python to integrate into our Dockerfile.
I also have a script that does more or less the same. It was inspired by work from the infra team.

[MarkEWaite]

I also have a script that does more or less the same. It was inspired by work from the infra team.

That looks much better suited to the automation needs of the project than my interactive scripts. Nicely done!

[gounthar]

Thanks a lot, Mark, I do appreciate it. 🤗
It had to be automated because I use it to create automatic pull requests to keep my project up to date. 🤷

[gounthar]

As per today's meeting, the update could happen within the existing testing GitHub Action, or in a Jenkinsfile, or even thanks to updatecli, but it would be better to create a new GitHub Action with a bash script.
In a GitHub Action, we already have the gh tool, the right variables that will allow us to easily create a PR, and we already have the building blocks to get a Jenkins instance working, ready to be updated.