Customize Jenkins with Plugins

This document shows how to customize Jenkins with plugins.

Installing additional plugins

Due to possible plugin dependency issues, installing additional plugins can be a risky operation. With Carthago, you can test plugin configuration on a non-production Jenkins Controller.

To install additional plugins, you need to add them to the list of plugins under Jenkins Custom Resource’s spec.plugins section like so:

apiVersion: carthago.cloud/v1beta1
kind: Jenkins
metadata:
  name: example
spec:
  plugins:
    - name: "name-of-the-plugin"
      version: "3.14"

After applying modifications to Jenkins Custom Resource spec.plugins, Operator will automatically install plugins after Jenkins Controller pod restarts.

For extra caution, monitor your Jenkins Controller pod logs while installing plugins to discover any problems with plugins. You can see how to do this in Troubleshooting section.

Bumping versions of plugins installed by Operator

By default, Operator installs the following plugins:

configuration-as-code
git
job-dsl
kubernetes-credentials-provider
kubernetes-client-api
kubernetes
workflow-aggregator
workflow-job

If you need to install one or more of these plugins in specific versions, simply specify them under Jenkins Custom Resource’s spec.plugins section like you would with additional plugins.

Note on caching plugins

Operator caches downloaded plugins by itself, so that on next installations of the same plugin versions (for example, after a Jenkins restart) Operator doesn’t have to download them again and can instead use versions from cache.

Operator does that by mounting a Persistent Volume to store plugins. You can edit its properties in Jenkins CR (Custom Resource) under spec.pluginsCache. To learn what you can configure there, visit PVCOptions section in API Schema docs

Plugin cache is not available in the free plan, and requires a valid license.