skip to content

Plugins & Ecosystem

2 roadmaps5 questions

The plugin manager and the handful you always meet - Git, Pipeline, Credentials, Docker, Kubernetes, Blue Ocean - plus the LTS and compatibility constraints that make upgrades risky. Asked because plugin sprawl is the main reason an old Jenkins install is hard to maintain.

part ofJenkinsoverview, primer and where to startread it →
on this pageshow

explore

questions

5

In Jenkins, what is a plugin, and what does the Plugin Manager actually do when you install one?

level: juniorimportance: must knowfreq 70%

answer

  1. core is small, features come from elsewhere
  2. .hpi or .jpi under JENKINS_HOME/plugins
  3. manifest declares minimum core and dependencies
  4. @Extension registers into core's registry
  5. most need a restart to take effect

basics

~20 s

A Jenkins plugin is a packaged extension (.hpi/.jpi) supplying almost everything Jenkins does beyond scheduling builds. The Plugin Manager downloads it plus its declared dependencies into JENKINS_HOME/plugins and loads it, in many cases only after a restart.

solid answer

~50 s

Jenkins core is deliberately small — it stores jobs, schedules builds and serves a UI. Git checkout, Maven builds, Pipeline itself, the credentials store, Docker and Kubernetes agents all arrive as plugins. A plugin is a Java archive with a `.hpi` or `.jpi` extension whose `META-INF/MANIFEST.MF` declares its own version, the *minimum* Jenkins core it needs (`Jenkins-Version`) and its plugin dependencies. It is loaded into the same JVM as core and registers itself through extension points — classes annotated `@Extension` are discovered at startup and appear in the relevant dropdowns. When you install from Manage Jenkins → Plugins, Jenkins reads the update site catalogue, resolves the dependency graph (so you often get plugins you never ticked), downloads each file into `$JENKINS_HOME/plugins`, and either loads it dynamically or waits for a restart. A safe restart drains running builds first.

code

bash · 2 lines
bash
# Inventory a controller's plugins from the CLI (token in token.txt)
java -jar jenkins-cli.jar -s "$JENKINS_URL" -auth @token.txt list-plugins

go deeper

for a junior

Be able to say that Jenkins core does little on its own and that plugins supply Git, Pipeline, credentials and agents. Know that they are installed from Manage Jenkins and usually need a restart.

for a middle

Explain the mechanics: the manifest declares a minimum core version and dependencies, extensions register at startup, and files land in JENKINS_HOME/plugins as .jpi with a .bak of the previous version.

for a senior

Show that you treat the plugin set as controller state: it lives in JENKINS_HOME, it is restored with your backup, and transitive dependencies mean an install changes more than the one thing you ticked.

for a principal

Frame the plugin model as an architectural choice — extensibility bought with a shared JVM and no isolation — and be ready to say what that costs an organisation in upgrade coupling and trust.

## What "plugin" means in Jenkins Jenkins core is small on purpose: it persists job definitions, schedules builds, dispatches them to agents, and serves a web UI. Nearly every capability a team actually uses — checking out from Git, publishing test results, storing credentials, defining a Pipeline at all, provisioning containerised build machines — arrives as a plugin. That is why a fresh install opens a setup wizard offering "Install suggested plugins": an empty Jenkins does very little. A plugin is a Java web-application archive with Jenkins-specific metadata, distributed as a file ending in `.hpi` (the historical Hudson extension) or `.jpi`. Inside are compiled classes, view files for the UI, static resources, and a `META-INF/MANIFEST.MF` that Jenkins reads *before* loading any code: ``` Plugin-Version: 5.2.2 Jenkins-Version: 2.426.3 Plugin-Dependencies: credentials:<version>,scm-api:<version>;resolution:=optional ``` `Plugin-Version` is the plugin's own release. `Jenkins-Version` is the **oldest** core it will run on. `Plugin-Dependencies` lists other plugins with minimum versions, some marked optional. ## How it plugs in Plugins are not separate processes and not sandboxed. Each gets a classloader inside the controller's JVM and registers itself through *extension points*: core (and other plugins) define interfaces such as SCM implementations or build steps, and a plugin class annotated `@Extension` is discovered at boot and added to the matching registry. Nothing lists the Git plugin in a config file — installing it makes "Git" appear in every job's SCM dropdown because the extension registry now contains it. ## What the Plugin Manager does on install Manage Jenkins → Plugins talks to an *update site*, by default `updates.jenkins.io`, which publishes a JSON catalogue: available plugins, versions, dependencies, required core version, deprecation flags and security warnings. When you tick one and install: 1. Jenkins resolves the dependency graph and queues transitive dependencies you never asked for. 2. It refuses or warns if the version's `Jenkins-Version` is newer than the running core. 3. It downloads each archive into `$JENKINS_HOME/plugins/`, stored as `<shortname>.jpi` with an exploded directory beside it. 4. It either dynamically loads the plugin or marks it pending a restart. Many plugins cannot be hot-loaded, because other components must see their extensions at startup. Finishing with a *safe restart* — the "Restart Jenkins when installation is complete and no jobs are running" checkbox, or the `safe-restart` CLI command — stops scheduling new builds, waits for running ones, then restarts. ## Where plugins live, and why that matters `$JENKINS_HOME` is the entire state of a controller, and `$JENKINS_HOME/plugins` is the entire plugin set: there is no separate registry and no per-job installation. Back up JENKINS_HOME and you have captured your exact plugin versions; lose it and you have lost them. When a plugin is upgraded the previous file is kept alongside as `<shortname>.jpi.bak`, which is what the Installed tab's "Downgrade" button restores. ## Detached plugins Several features that once lived in core were later "detached" into plugins — JUnit result publishing and matrix authorization among them. Core still declares them, so upgrading an old Jenkins auto-installs the detached plugins it needs. That is another route by which plugins you never chose appear in the Installed list. ## The names you are expected to recognise - **Git** and **GitHub Branch Source** — checkout and repository/branch discovery. - **Pipeline** (`workflow-aggregator`) — an umbrella plugin pulling in the components that make a `Jenkinsfile` work at all. - **Credentials** and **Credentials Binding** — the credential store and its use inside builds. - **Docker** and **Kubernetes** — provisioning build agents on demand. - **Blue Ocean** — the alternative pipeline UI, now in maintenance mode; the project points new users at the Pipeline: Graph View plugin. - **Configuration as Code** (JCasC) — describing controller configuration as YAML. ## The consequence interviewers are really probing Because plugins share the controller's JVM, classloading and privileges, a plugin set is not a bag of independent add-ons — it is one coupled application assembled at runtime from parts on independent release schedules. Every later Jenkins maintenance problem grows from that: version coupling to core, dependency upgrades you did not request, security advisories that reach the whole controller, and the sprawl that makes an old install hard to move.

  • Why do most Jenkins plugins require a restart before their features appear?
    Extensions are discovered and wired at startup, and other components resolve against them then. Only plugins built for dynamic loading can be added to a live controller, and even those can leave half-initialised state. A safe restart is the reliable path: it stops scheduling new builds, waits for running ones to finish, then restarts the controller.
  • What are "detached" plugins in Jenkins?
    Features that once shipped inside core and were later split into plugins — JUnit publishing and matrix authorization, for example. Core still declares them as dependencies, so upgrading an older Jenkins installs them automatically. It is one reason the Installed list contains plugins nobody on the team ever chose.
  • How would you get a machine-readable inventory of what a controller has installed?
    Three ways: the CLI's `list-plugins`, the controller's REST API at `/pluginManager/api/json?depth=1`, or simply listing `$JENKINS_HOME/plugins`. The API is the usual choice for automation because it returns short name, version, enabled state and whether an update is pending, which is exactly what a drift check needs.

saying these in an interview costs you the question

  • Says plugins run sandboxed or in their own process
  • Thinks Jenkins can clone a Git repo with no plugin
  • Claims installing a plugin never needs a restart
  • Assumes only the ticked plugins get installed
  • Looks for plugins in the job config rather than JENKINS_HOME

context

resolving links…

open as a page

Why can upgrading Jenkins plugins be risky, and what does the LTS release line have to do with it?

level: middleimportance: should knowfreq 55%

basics

~20 s

Plugins and Jenkins core release on separate schedules, and each plugin declares a minimum core version. Upgrading one plugin can pull its dependencies, the core, and even the JVM forward — so upgrades are coupled, never isolated.

open as a page

How would you make a Jenkins controller's plugin set reproducible instead of installing plugins by clicking in the Plugin Manager?

level: seniorimportance: should knowfreq 42%

basics

~20 s

Describe the plugin set as a pinned list in a file, install it at image-build time with jenkins-plugin-cli, and keep controller configuration in Configuration as Code YAML. Upgrades become a reviewed diff; rollback is redeploying the previous image.

open as a page

In Jenkins, how much trust does an installed plugin actually get, and how do you handle a security advisory against one you depend on?

level: seniorimportance: should knowfreq 38%

basics

~20 s

A Jenkins plugin runs inside the controller JVM with the controller's full privileges — every stored credential, all of JENKINS_HOME, the network. There is no per-plugin sandbox, so trusting a plugin means trusting it with the whole controller.

open as a page

A long-lived Jenkins controller has grown to roughly 200 installed plugins. How do you decide what to remove, and what does removing one actually cost?

level: principalimportance: nice to knowfreq 28%

basics

~20 s

Grade each plugin by evidence of use, maintenance status and whether a scripted alternative exists. Removal is not free: job configs referencing it stop deserializing, so plan for old-data breakage — and often a curated rebuild beats pruning in place.

open as a page