Jenkins Anti-Patterns

This lesson covers

Security anti-patterns → Pipeline anti-patterns → Operations anti-patterns → Organisational anti-patterns → The warning signs checklist → What good Jenkins looks like

The Analogy

Jenkins anti-patterns are like technical debt in a codebase. Each one is small and harmless on its own. But they compound. A credential hardcoded "just for now" becomes a permanent fixture. A pipeline with no timeout "never hangs anyway." No backup "because nothing has gone wrong yet." Three years later, one outage hits all three simultaneously and the post-mortem reads like a checklist of everything this lesson warned about.

Setting the master executor count above 0 means build scripts run with access to the entire JENKINS_HOME, all credentials, and all plugin state. A malicious or accidentally broken build script can read, modify, or delete anything Jenkins manages. Set master executors to 0. Always.

Any authenticated user — including contractors, interns, and compromised accounts — has full admin rights. They can install plugins, modify security settings, read all credentials, and delete any job. Covered in Lesson 28 — but worth repeating because it's still found in the wild constantly.

A pipeline with no timeout() will hang forever if a waitUntil never resolves, a shell command blocks on stdin, or an external API stops responding. One hung build holds an executor for days, silently starving every other build in the queue.

options { timeout(time: 30, unit: 'MINUTES') }

A Jenkinsfile that parses JSON, generates dynamic stage names, loops through service lists, and implements custom retry logic — all inline — is unmaintainable. Nobody reviews it properly in PRs because it's too long to read. Nobody fixes it because nobody fully understands it. Changes break things nobody expected.

Wrapping a test step in retry(3) because "it sometimes fails" is hiding a real problem — a non-deterministic test, a race condition, or an external dependency without proper stubbing. The test passes in CI, ships to production, and fails in production where you can't retry three times automatically.

Sending a Slack message for every successful build trains the channel to be ignored. When a real failure notification arrives, it's buried in the noise. Teams mute the channel. The value of the notification system collapses to zero.

agent { docker { image 'node:latest' } } means your build environment changes silently whenever the upstream image is updated. A Node.js major version bump, a Java security patch that breaks an API, a dependency change in the base image — all land invisibly in your CI without a PR, a review, or a Changelog entry.

agent { docker { image 'node:20.11-alpine3.19' } }   // pinned — explicit upgrade required

The most expensive anti-pattern. JENKINS_HOME contains every job config, all credentials, the entire build history, and all plugin configurations. It lives on one disk, on one server. When that disk fails — and it will — the question is whether you have a backup from last night or a backup from never.

Without buildDiscarder(logRotator()), jobs accumulate thousands of builds indefinitely. Each build stores logs, test results, and artifacts. After 6 months of active use, JENKINS_HOME is 200GB and the UI loads slowly because every page request scans the entire build history.

options {
    buildDiscarder(logRotator(numToKeepStr: '20', artifactNumToKeepStr: '5'))
}

Each plugin is code that runs on every request, hooks into Jenkins internals, and must be kept updated for security. A Jenkins with 150 plugins — 80 of which nobody uses — has 80 attack surface vectors, 80 potential compatibility failures on upgrade, and 80 reasons the UI could load slowly.

A Jenkins configured only through the UI has no version history, no review process, and no recovery path if the server dies. Every change is a silent, unreviewable modification to a black box. When the server needs to be rebuilt, you start from scratch trying to remember what you configured three years ago.

When the only person who knows how Jenkins works goes on holiday, gets sick, or leaves the company, the entire CI/CD system becomes a black box nobody can maintain. Any outage becomes a crisis because the institutional knowledge walked out the door.

A red build that everyone ignores because "it'll fix itself" or "that's the infrastructure team's job" creates a broken windows effect. Teams stop trusting the pipeline. They start bypassing it. Deployment discipline erodes. By the time someone fixes the root cause, nobody remembers the pipeline was supposed to be the safety net.

When the Jenkins UI is slow and builds are queueing, the instinct is to add more agents. But if the master is the bottleneck — high CPU, heap pressure, thread exhaustion — adding agents increases master load and makes the problem worse. This anti-pattern causes expensive cloud bills and continued degradation.

Teacher's Note

If you walked through this lesson and recognised five of these anti-patterns in your own Jenkins — that's normal. This is what real production Jenkins systems look like. The value of this lesson is recognising them before the next incident makes them unavoidable.

Up Next · Lesson 45

Mini Project — End-to-End CI/CD Pipeline

Everything from this course comes together. Build a production-grade CI/CD pipeline from scratch — Git, Docker, Kubernetes, security, notifications, and failure handling — in one complete real-world project.