Jenkins Configuration as Code: Plugins

NOTE: This blog discusses a feature no longer available in Jenkins Configuration as Code. Please refer to CloudBees technical documention for CloudBees Jenkins Distribution and CloudBees CI for more information on configuration as code functionality.

This blog post is the third in a six-part series on configuration as code.

Using configuration as code, one can manage Jenkins controller’s configuration with simple, declarative YAML files, and manage them as code. But managing Jenkins is not only about jenkins-core, it’s also about the many plugins one needs to select and install to provide useful features.

A recurring question on the Jenkins Configuration as Code (JCasC) functionality is to know how to support plugins.

This is what one would expect when thinking about how to improve the Jenkins ecosystem, where each and every plugin needs to be implemented with a fresh, new API so it can contribute a new model. This is typically what happens when a Jenkinsfile pipeline DSL gets introduced.

However, this is not the case with JCasC. By design, JCasC can configure any Jenkins component which follows some reasonable conventions. JCasC actually relies on the web user interface (UI) data-binding mechanism, which any plugin uses to manage configuration forms. In doing so, we ensure we are always up-to-date with the plugin model and can say we support most plugins out-of-the-box. For the plugins that don’t fit into this model, they only require some minor fixes to adopt well-established UI data-binding conventions. We expect the Jenkins ecosystem will move fast and adopt these development practices.

For the few strictly incompatible plugins, we also offer a “support” module with dedicated glue code to adapt JCasC requirements to the actual design of weird plugins.

Configuring plugins without the need for dedicated glue code is nice, but one still needs to install those plugins and fight dependency hell.

Jenkins Configuration as Code can manage plugin installations for you. As with any Jenkins component, the PluginManager is configurable and includes a dedicated configurator to manage the special scenario and constraints of plugin installation.

You just need to notice that the Jenkins Configuration as Code is a plugin, so it needs to be installed first.A YAML configuration with a plugin requirement will trigger an installation.

plugins:
required:
  git: 3.6.0
  chucknorris: 1.0
  myplugin: <a href="http://repo.mycompany.com/jenkins/myplugin-1.0.jpi">http://repo.mycompany.com/jenkins/myplugin-1.0.jpi</a> 

During startup, Jenkins Configuration as Code will retrieve metadata from the update center and install the requested plugin version. Compare it to the Plugin Manager’s web UI, and select the version of plugins to be installed to ensure reproducibility. You also can use the “latest” version if you don’t care very much about plugin installation reproducibility.

Jenkins Configuration as Code will also resolve plugin dependencies and install required ones. Here again, to ensure reproducibility it will create a shrinkwrap text file with a full list of installed plugins, so future runs of Jenkins Configuration as Code with the exact same configuration will install the same set of plugins. This mechanism is not only inspired from the Node Packet Manager (NPM) build tool to offer a high-level declarative abstraction for dependencies, but the shrinkwrap file will also fix dependencies once the project is set to ensure reproducibility in a versatile ecosystem.

Last but not least, users can replace the "version" attribute for a plugin they want to install with a full download URL. This is useful for those who want to install custom plugins, not being hosted in a fully-featured Jenkins update center, or have trouble using an update center which doesn’t expose metadata about plugin versions, but rather only for the latest one.

You can read more about the Jenkins Configuration as Code plugin on the project’s GitHub repository . To chat with the community and contributors join our gitter channel Or come see us in person at DevOps World | Jenkins World 2018 to discuss the JCasC project and its future!

Also don’t miss the next post from the configuration as code series...

Part 1: Jenkins Configuration as Code: Look Ma, No Hands

Part 2: Jenkins Configuration as Code: Sensitive Data