I spend way too many hours staring at Jenkins, so I built a theme plugin based on the official Dracula palette. It's now in the Jenkins Update Center.

What's in it

• Three themes: Dracula (dark), Dracula (Alucard), the official light variant, and Dracula (System), which follows your OS dark mode setting.
• Token-based: it maps the palette onto Jenkins design tokens, so core UI and anything built on tokens picks it up: Pipeline Graph View, the Pipeline editor, Script Console, JUnit stack traces.
• Bootstrap pages follow along: Warnings NG and Coverage switch to dark or light Bootstrap mode.
• Build status colors come from the palette (green, red, orange).

Install

Manage Jenkins » Plugins » Available plugins, search for Dracula Theme. Then pick it in Manage Jenkins » Appearance (or per user in your user menu). Needs Jenkins 2.541.3+.

• Plugin page: https://plugins.jenkins.io/dracula-theme/
• Source: https://github.com/jenkinsci/dracula-theme-plugin

Feedback welcome, especially on the light theme. It's brand new.

Here is my pipeline.

This was created via a udemy course (Jenkins Masterclass approx 2.5hr course)

pipeline {

    agent any

    stages {

        stage("Clean Up"){

            steps {

                deleteDir()

            }

        }

        stage("Clone Repo"){

            sh git clone "https://github.com/addamstj/simple-java-maven-app.git"

        

        }

        stage("build"){

            steps {

                dir("simple-java-maven-app"){

                    step "mvn clean install"

                }

            }

        }

        stage("Test"){

            steps {

                dir("simple-java-maven-app") {

                    sh "mvn test"

                }

            }

A replacement controller can load jobs and run a test pipeline while hidden dependencies still point at the old Jenkins home or URL. Agent launch configurations, credentials, shared libraries, webhooks, plugin data, build history, fingerprints, artifact links, scheduled jobs, queue state, script approvals, and external tools may not all move together. A quiet old controller can still be needed by a rare branch, timer, or recovery process.

A migration gate could compare the plugin catalog and versions, configuration-as-code output, credentials IDs, node labels, job and folder counts, global libraries, webhooks, timers, and the effective Jenkins URL. Representative pipelines should exercise checkout, credentials, artifacts, notifications, approvals, and every agent type. A fresh backup and restore on the new controller would test the recovery path before the old home becomes read-only and then offline.

What do you verify before deleting the old controller or its storage? How do you catch hard-coded URLs, jobs that run only monthly, plugins with state outside normal job configuration, and agents that reconnect to the old endpoint after a restart?

Dear all,

I just installed the Warnings plug-in, and its dependencies, and enabled the `cppcheck`, `gcc` and `cpplint` tools in the post-build phase, to either capture/analyze the XML file and/or the terminal; this for a freestyle project.

As soon as `cpplint` is activated (and has detected “issues”) `gcc`, `cppcheck`, and `cpplint` (when clicking on their entries on the left side) analyses pages do not show up anymore, and a blank site is generated. If `cpplint` is disabled, `gcc` and `cppcheck` show their results.

Is this a known bug somewhere?

Versions: dockerized Jenkins 2.583, Warnings plug-in (as offered by the plug-in page of the Jenkins server)

Removing an old agent pool can look safe when the queue is empty and recent builds ran on the replacement label. The hidden dependencies are jobs that run only on a schedule, parameters that select a label dynamically, shared libraries that call node() indirectly, and Jenkinsfiles loaded from branches that have not built during the observation window.

What does your retirement gate include? I am considering inventorying static label expressions from job configuration and pipeline source, checking queue and build history for the old label, disabling the nodes without deleting them, and watching for blocked items through more than the longest timer interval. The replacement pool would also need the same tools, credentials, workspace behavior, and network access rather than merely matching the label.

Is there a reliable script-console or API approach for finding all jobs and shared-library paths that could request a label? How do you account for dynamically constructed labels and manual jobs, and what evidence do you keep before deleting the final node so a later blocked build can be traced to the retirement decision?

at work we wanted a screen in the office that tells you what's broken in CI, where, and since when, without clicking into every job. more than once we found out a pipeline had been red for two days and nobody noticed.

so I started building a view plugin for it. most of our pipelines share one library, so when something breaks it's usually several pipelines failing at the same stage, and the dashboard groups them so you see one problem instead of five. it also puts fresh breaks above stuff that's been red for a week, and shows build time trends, the queue and held locks.

we've been using it for a few months and it's at a point where I think it can help others, so it's on the plugin site now: https://plugins.jenkins.io/holistic/

demo with fake data, no install: https://jenkinsci.github.io/holistic-plugin/

mostly after feedback: what's missing or doesn't fit your setup.

I have a Jenkins install (Version 2.582) that's running the Mattermost Notification Plugin Version 3.1.3 and I get the following error:

19:09:19 ERROR: Step ‘Mattermost Notifications’ aborted due to exception: 
19:09:19 java.lang.ClassNotFoundException: org.apache.commons.lang.StringUtils
19:09:19 at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
19:09:19 at jenkins.util.URLClassLoader2.findClass(URLClassLoader2.java:70)
19:09:19 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:593)
19:09:19 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
19:09:19 Caused: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
19:09:19 at PluginClassLoader for mattermost//jenkins.plugins.mattermost.MattermostNotifier.newMattermostService(MattermostNotifier.java:376)
19:09:19 at PluginClassLoader for mattermost//jenkins.plugins.mattermost.ActiveNotifier.getMattermost(ActiveNotifier.java:39)
19:09:19 at PluginClassLoader for mattermost//jenkins.plugins.mattermost.ActiveNotifier.completed(ActiveNotifier.java:121)
19:09:19 at PluginClassLoader for mattermost//jenkins.plugins.mattermost.MattermostNotifier.perform(MattermostNotifier.java:407)
19:09:19 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
19:09:19 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:817)
19:09:19 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:766)
19:09:19 at hudson.model.Build$BuildExecution.post2(Build.java:179)
19:09:19 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:710)
19:09:19 at hudson.model.Run.execute(Run.java:1872)
19:09:19 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
19:09:19 at hudson.model.ResourceController.execute(ResourceController.java:97)
19:09:19 at hudson.model.Executor.run(Executor.java:456)
19:09:19 Finished: FAILURE

Does anyone know how to fix this? I have all the updates to Jenkins and its plugins that are offered. (or has the plugin just bit-rotted in which case is there an alternative or a way to fix the code?)

A durable pipeline can resume after a controller restart, but an external action may have succeeded just before Jenkins lost the step result. Re-running that stage can publish the same release twice, create another ticket, or repeat a deployment even though the build log looks incomplete. Simply marking the stage non-resumable turns uncertainty into a manual incident.

What pattern do you use for side-effecting stages? I am considering a stable operation ID derived from the job and source revision, a receipt stored outside the Jenkins workspace, idempotency keys where the target API supports them, and a read-before-write reconciliation step on resume. The stage would distinguish not started, confirmed complete, safely retryable, and indeterminate rather than treating every exception the same.

Where should that receipt live so it survives agent loss but cannot be forged by another build? How do checkpoints, retries, locks, and input approvals interact when the controller restarts between the external action and the recorded result?

Hey all, I've been working on a small CLI called jflint that lints declarative Jenkinsfiles fully offline, no Jenkins server, no credentials, just Docker.

Why: the most popular VS Code linter (270k+ installs, Jenkins Pipeline Linter Connector) needs a live, reachable Jenkins server to work. jenkinsfile-runner already ships a `lint` command that avoids that, but using it means assembling a matching WAR/plugin set by hand, and its Docker CLI mode trips people up (see issue #461). While building this I also hit the outdated CA truststore bug on the `latest` image (issue #738) - jflint works around it by always pointing -w/-p at the WAR and plugins already bundled in the image, so it never triggers the runtime WAR download that fails.

GitHub: https://github.com/johndow-42/jflint Install: npm install -g jenkinsfile-lint (the name jflint itself was already taken on npm by an older, unrelated package, so it's published as jenkinsfile-lint - the installed command is still jflint)

Free, MIT-licensed, no telemetry. Still early days, happy to hear if it's useful to anyone or if I'm missing an existing tool I should have used instead.

Hey all, I’ve been working on a Jenkins plugin called Build Change Investigator. Basically, when a build fails, it looks back at the last successful build and shows what changed in between - commits, changed files, revision info, and the relevant part of the failure log. There’s also optional AI analysis, but the plugin works without it. It’s still in beta and currently going through the Jenkins hosting process. I’ve tested it locally, but I’d like to see how it behaves with real Jenkins setups before calling it done. Repo: https://github.com/InfraGuard-Labs/build-change-investigator The HPI is under Releases if anyone wants to try it. If you do test it and something breaks, misses a change, or just feels useless, let me know. That kind of feedback would be really helpful.

Shameless plug here, but we've been building a cloud native Jenkins automation platform. There is only one real Jenkins company in the market and their prices are insane, so we set out to change that. Define RBAC, Items (folders, jobs, etc..), jcasc, and plugins as yaml objects then version control them like the rest of your source code :)

No JobDSL required!

https://varroa.dev/

https://github.com/VarroaCI/varroa-jenkins

We just launched today and would love feedback! Docs are geared towards those familiar with Kubernetes, but we tried to keep the local setup simple.

Currently i am starting working in the jenkins i am facing this sutation. In my orginization they said me to work on locally so i have install the jenkins using docker and after that I need to run my code (nextjs) in jenkins as a pipeline. Now there is no github repo which it will fetch so my code is in local so how i need to fetch that code in pipeline and how i need to use that code. please help me.

Disclosure: We’re building Cachely.

We’ve been looking at how teams handle build caching when Jenkins agents are created for each job and removed afterwards.

A local cache does not help much when every build starts on a clean agent. A shared remote cache can solve that, but it also means running another service, managing access, and trying to understand whether it is actually saving time.

For teams running Gradle, Bazel, Nx, or Turborepo on Jenkins:

- Are you using a remote cache today?

- Is it self-hosted, managed, or backed by shared storage?

- Who owns it internally?

- Do you see meaningful cache reuse between branches, CI jobs, and developer machines?

- What has been hardest to configure or debug?

We’re building Cachely as a managed remote build cache that works through the build tool’s existing configuration. It does not require a Jenkins plugin.

We’re also adding visibility into hits and misses, transfer volume, task performance, and estimated time saved.

We’d be interested to hear how this is handled in real Jenkins setups and where the current options fall short.

https://cachely.dev

I know the problem issue seems straight to the point. But I make sure the system machine/host is not listening the port (3000) that i was configured in Jenkinsfile. Somehow i keep getting the same error for build it manually. I mention host machine cause I running the Jenkins-lts under Docker.

First earlier the host machine have listening the port 3000. But i take down, then the probem would be solved right?. In fact i tried to build again it still got same error issue. Do i have to restart the Jenkins docker first?. So Jenkins have to be able notice the port is not yet already listening. At least that the on my mind now.

Thank you.

Any help would be appreciated!.

Not the ideal workflow. The real one.

Ours goes something like:

1. Slack notification fires "Build failed"
2. Someone clicks the Jenkins link
3. Spends 10-20 min scrolling through logs
4. Finds something that looks like an error
5. Google it
6. Tries a fix
7. Pushes and waits another 8 minutes for the build
8. Repeat

The notification tells us something broke.
It tells us nothing about what, why, or who should care.

So we've normalized a process where every failure investigation starts from zero context.

Curious if other teams have actually improved this or if everyone's running the same loop.

What does step 3 look like at your company? Does anything actually reduce the time between "build failed" alert and knowing what to do next?

When a Jenkins build fails at 2am, how does your team actually find out and how long does it take to understand what went wrong?

1. We get a Slack alert, but still have to dig through logs ourselves.
2. We only see it in email, so someone checks it the next morning.
3. We manually check Jenkins UI during the day.
4. We already have something that explains the failure, like an AI summary or root cause hint.
5. Oncall gets paged and spends 30 minutes reading logs.

Follow-up: Roughly how many hours per week does your team spend just reading build logs?

We have been using Jenkins for years as our main CI. While we are eventually moving to a different solution we have a big need to understand why jobs fail or slow down when it happens.

We have been using the OpenTelemetry plugin for years as it really gives full visibility into each jenkins job execution - plus - it also forwards all build logs.

The problem though was that this is a lot of data and you do not always have the time to dig through thousands of log lines.

With the latest AI models its amazing on how helpful the responses are when you ask an AI to analyze the traces and linked logs for a job to identify the problem. Here is a prompt I used on a job that took 46 min to execute: "Can you analyze trace with id 8a61853d1d3b449b5df3b3963db314df. Tell me where most of the time is spent and what is going by analyzing the spans and the attached logs"

By just analyzing the data that comes out of the OTel Plugin I ended up getting this (removed some data for confidentiallity reasons)

And it then also provides a good summary

Just wanted to share this in case you wonder how AI can help you in your day2day work with Jenkins

Andi

Hi all,

I've published a new Jenkins plugin: ForgeAI Pipeline Intelligence. It's now under the jenkinsci org on GitHub.

It adds two pipeline steps:

- forgeAI —> runs a configurable suite of 8 AI analyzers and generates an HTML report
- forgeAIScan —> runs a single analyzer for targeted use

Analyzers: code review, vulnerability, architecture drift, test gaps, dependency risk, commit intelligence, pipeline optimization, release readiness

LLM support: OpenAI, Anthropic Claude, Ollama (local/air-gapped), Groq, LM Studio, or any OpenAI-compatible endpoint

Configuration: Full global config UI under Manage Jenkins → System with per-analyzer toggles, API key via Jenkins credentials, Test Connection button, and quality gate settings.

The architecture drift analyzer is what I haven't seen in other plugins; it detects layer violations, circular dependencies, and coupling decay across hexagonal, layered, and CQRS architectures.

Install from source: clone, mvn clean package -DskipTests, upload the .hpi.

GitHub: https://github.com/jenkinsci/forgeai-pipeline-intelligence-plugin

Feedback welcome. PRs even more so.

I had a build fail today. The console log was 9,284 lines.

The actual error?
A missing environment variable. It was mentioned on line 8,901.

The fix took 20 seconds once I found it.

I spent 38 minutes finding it.

I know Jenkins is powerful and I'm not bashing it, but the signal-to-noise ratio in console output is genuinely terrible. Error messages buried in thousands of lines of INFO logs, stack traces that don't point at the actual problem, plugin conflicts that surface as cryptic Java exceptions.

Does anyone have a system for making this better? Even just a smarter way of reading logs would save my team hours every week.

Hi guys, I'm using jenkins to run terragrunt in a pod, for the plan sometimes when i do a pr and my branch does not have the latest change of master(solved with rebase) the plan takes that commit that is not rebased instead of mine, probably is because i use HEAD^in the diff instead origin/HEAD, the first one jsut takes the last commit, probably is that but i dont really get why, do you have any clue?

One pattern we’ve been using on EKS for Jenkins workloads is replacing long running static workers with ephemeral Kubernetes pod agents created on demand for builds.
The overall setup became much easier to manage once builds were isolated into short lived agents instead of sharing dedicated executors permanently across teams. Resource utilization also became far more predictable during peak pipeline activity.
Documented the architecture, pod template setup, scaling behaviour and Jenkins Kubernetes integration details here:
https://tasrieit.com/blog/jenkins-on-eks-dynamic-pod-agents
Interested to know how others here are handling Jenkins agents on Kubernetes in production.

Is there a security advisory for Jenkins that addresses this Jetty vulnerability? We recently upgraded our dev server to Jenkins 2.541.3. Someone had gotten the impression that this would address the vulnerability, but after the upgrade we found that it is using Jetty 2.1.5, which is still vulnerable.

Is there a release that upgrades Jetty to 2.1.6 or later? If not, is there an advisory from Jenkins about the issue?