Plugins and the Controller–Agent Architecture

Plugins extend Jenkins (Git, Pipeline, SonarQube, Email Extension…); the controller schedules and hands builds to agents by label, and agents run them on executors.

Plugins are the main way to extend Jenkins — over 1,000 plugins for SCMs, build tools, clouds, code analysis and notifications. Manage them under Manage Jenkins → Plugins or through the CLI.

Plugin	Configuration	Use in the pipeline
SonarQube Scanner	Scanner under Tools, server under System (give it a name, e.g. `sonar-server`)	`withSonarQubeEnv('sonar-server') { sh 'sonar-scanner' }`
Email Extension	SMTP under System	`emailext subject: ..., body: ..., to: 'admin@example.com'` (usually in `post`)
Git, Pipeline (`workflow-aggregator`)	Usually installed with the suggested set	`git`, `checkout scm`, `pipeline { }`

Controller–agent architecture (formerly called master–slave):

flowchart TB
  C["Controller<br/>schedules, UI, stores config, gets results"]
  C -- "job label linux" --> A1["Agent linux<br/>2 executors"]
  C -- "job label windows" --> A2["Agent windows"]
  C -- "agent docker" --> A3["Docker / Kubernetes agent<br/>created on demand"]
  A1 -- "console output, results" --> C

Controller: schedules jobs, hands builds to agents, tracks agents online/offline, receives results and shows the console output.
Agent (node): a machine that runs builds; each agent has a number of executors (concurrent builds) and labels for selection: agent { label 'linux' }.
Connecting agents: SSH from the controller, or inbound agents that connect back (TCP 50000 or WebSocket).
Set the controller's executor count to 0 so builds always run on agents.

Traps: the name in withSonarQubeEnv('...') not matching the configured server name; running heavy builds on the controller; installing plugins carelessly (each one adds attack surface and upgrade burden).

Command	Meaning
`java -jar jenkins-cli.jar -s http://localhost:8080/ -auth @/home/fresher/.jenkins-cli-auth list-plugins`	List plugins
`java -jar jenkins-cli.jar -s http://localhost:8080/ -auth @/home/fresher/.jenkins-cli-auth install-plugin git workflow-aggregator -restart`	Install plugins, then restart

Agents that come and go

Static agents run all the time; cloud agents are created per build and removed afterwards, giving a clean environment every time and costing nothing while idle:

Plugin	Agent comes from
Kubernetes	A pod per build in a Kubernetes cluster
Docker	A container on a Docker host
Amazon EC2 / Azure VM Agents	A cloud VM launched on demand

With the Kubernetes plugin, a pipeline describes its own build pod:

agent {
  kubernetes {
    yaml '''
      spec:
        containers:
        - name: node
          image: node:22-alpine
          command: ["sleep", "infinity"]
    '''
  }
}
steps { container('node') { sh 'npm ci && npm test' } }

Tools on agents

The Tools page installs JDKs, Maven, Node.js, or the SonarQube scanner automatically on agents, used in a pipeline with a tools { maven 'maven-3.9' } block. Running each stage inside a Docker image is often simpler: the image pins the exact tool versions.

Choosing plugins carefully

Prefer well-maintained plugins with recent releases and many installations.
Remove unused plugins; each one adds startup time, memory, and security exposure.
Pin plugin versions in a plugins.txt file and install them with the Plugin Installation Manager tool when building a Jenkins image, so upgrades are reviewed.
Read the Jenkins security advisories and update affected plugins promptly.

Other plugins worth knowing

Plugin	Purpose
Blue Ocean / Pipeline Graph View	Visual view of stages and logs
JUnit	Publishes test reports and trends
Timestamper	Adds timestamps to console output
Role-based Authorization Strategy	Permissions by role and folder
Slack Notification	Messages to a channel on success or failure

Agent security

Agents run untrusted code from pull requests, so isolate them from production networks, give them only the credentials their jobs need, and never run builds as root on the controller.