Important Dates	Time
Nomination of candidates open	August 1
Nomination of candidates closes	September 15
Voter registration opens and candidates announced	September 16
Voter registration closes	October 31
Voting starts	November 1
Voting closes	November 30
Results announced	December 1

Important Dates	Time
Nomination of candidates open	September 18
Voter registration opens	September 18
Nomination of candidates closes	October 27
Voter registration closes	November 05
Candidates announced & Voting starts	November 06
Voting closes	December 01
Announcing Results	December 11

	Java 6	Java 7	Java 8	Java 11
Vendor release date	December 11, 2006	July 7, 2011	March 18, 2014	September 25, 2018
Rapid adoption	October 2009 (11,193 installations)	February 2013 (10,997 installations)	February 2015 (12,210 installations)	November 2019 (10,094 installations)
Peak usage	March 2013 (47,244 installations)	June 2015 (68,681 installations)	February 2021 (261,468 installations)	N/A
Jenkins weeklies require next major version	May 2015 (21,798 installations)	April 2017 (40,569 installations)	June 2022 (185,286 installations)	N/A
Terminal decline in usage	May 2016 (10,283 installations)	March 2019 (10,123 installations)	N/A	N/A
Vendor End of Life (EOL)	December 31, 2015	July 31, 2019	At least November 2026	At least October 2024

Event Metadata Headers Key	Event Metadata Headers Value
ce-specversion	1.0
ce-type	org.jenkinsci.queue.entered_waiting
ce-source	job/test
ce-id	123-456-789

Structural Element	Example
Chore	`chore: improve logging`
Fix	`fix: minor bug fix`
Feat	`feat: add a new feature`
Breaking Change	`BREAKING CHANGE: reimplement`

Commit Message	Version Bump	SemVer Equivalent
`chore: improve logging`	`1.2.0` → `1.2.0`	No version bump
`fix: minor bug fix`	`1.2.0` → `1.2.1`	Increment in the patch version
`feat: add a new feature`	`1.2.0` → `1.3.0`	Increment in the minor version
`BREAKING CHANGE: reimplement`	`1.2.0` → `2.0.0`	Increment in the major version

Project Type	Configuration File(s) Read
Maven	pom.xml
Gradle	build.gradle
Make	Makefile
Python	setup.py setup.cfg pyproject.toml
Helm	Charts.yml
Node (NPM)	package.json

Jenkins Blog

Jenkins 2026 Community Award Winners

2026-05-26T08:43:08+00:00

cdCon 2026 just wrapped up in Minneapolis and this included announcing the winners of the Continuous Delivery Foundation and Jenkins Community Awards. The CD Foundation provides awards for the Top CDF ambassador, contributor, documenter, and end user. Anyone that is part of the CD Foundation can be nominated for these. Additionally, as a graduated project, Jenkins has three of its own awards:

Most Valuable Jenkins Advocate
Most Valuable Jenkins Contributor
Jenkins Security MVP

Thanks to the voters and to everyone who nominated candidates. We extend special thanks to all the nominees for their work in Jenkins. The project thrives because of its community, and the award recipients are outstanding examples of that spirit.

The 2026 Jenkins award winners are:

Security MVP: Kevin Guerroudj

Kevin has served on the Jenkins Security Team for many years. He helps manage the Jenkins Bug Bounty Program and has collaborated with fellow Security Team members to coordinate several Jenkins security releases.

Most Valuable Contributor: Daniel Krämer

Daniel is a member of the Jenkins Board and has been the major driving force behind the transition from JUnit 4 to JUnit Jupiter in the Jenkins ecosystem. Modernizing the testing stack across a project as large and long-lived as Jenkins is not a small task, but Daniel has been steadily moving this effort forward.

He provided the technical groundwork for the initial implementation of JUnit Jupiter in Jenkins. He has opened hundreds of pull requests to Jenkins core components and Jenkins plugins to complete the migration in those components. 150 of the top 250 most popular, actively maintained plugins have completed the transition to JUnit Jupiter. 35 of the top 250 plugins have open pull requests for their transition to JUnit Jupiter. Daniel’s work improves the reliability, maintainability, and future readiness of the Jenkins testing ecosystem.

Most Valuable Advocate: Bruno Verachten

Bruno has shown consistent dedication to the Jenkins community in 2025. His leadership in the Platform SIG has provided better support for ARM and RISC-V architectures.

For years, Bruno has been the driving force behind the Jenkins table at FOSDEM. From organizing the booth and preparing materials to coordinating volunteers, he consistently ensures that Jenkins is visible and represented at one of Europe’s largest open source gatherings. Bruno is always ready to listen to Jenkins users and bring their insights to the project.

AI Chatbot to Guide User Workflow (GSoC 2026)

2026-05-26T08:43:08+00:00

Hello everyone, I’m Daniele, an Italian computer science student, and this summer I’ll be working on the AI Chatbot to Guide User Workflow plugin during GSoC 2026.

I started contributing to Jenkins many months ago, and after following the official communication channels, I noticed how difficult it can be for beginners to understand the functionality of complex software like Jenkins. My goal is to create a plugin that’s useful for Jenkins beginners, but can also help every developer debug their own failed Jenkins executions, reducing the time spent fixing a specific error and maximizing productivity.

The plugin will allow you to connect the current application context to give the chatbot access to the current screen, logs, and pipeline configuration files.

The agent will be able to access data from a VectorDB to get information about documentation, plugin documentation, and even discussions on Discourse and Reddit. Using all this data, it will be possible to provide the most accurate response possible.

Here you can find a summary of the Plugin specifications.

Plugin architecture

Jenkins Plugin Frontend: Sidebar created in React + Vite Frontend. Here it is possible to see the chat history, pick an older chat or also start a new one. It also presents a specific button which lets the user make the decision of attaching the current context.
Jenkins Controller: The Jenkins Controller is fundamental as it is the bridge between the frontend and the FastAPI backend, it has the task to validate the authentication and decide if the user can access the backend or not.
FastAPI Backend: The backend is the core part of the plugin, I decide to opt with FastAPI as it is a very solid framework for building backend applications. The heart of the agent will be LangGraph which will manage the different reasoning states. The agent will have at his disposal different tools which will be useful to get more info as possible in order to give the most accurate response back to the user.
ChromaDB: In the vector db data different types of data will be stored as vectors, such as Jenkins Docs, Jenkins Plugins Docs, Discourse and Reddit Discussions.
LLM: choose a local open source LLM hosted with Ollama or a third party api.

The architecture is designed to be modular so that the user is free to decide where to host each component, on the same machine or on different ones.

Agent tools

Here you can find an example list of the tools that the agent will be able to use.

Hybrid Retrieval (VectorDB + BM25 Indexer)

Search Build Logs: Search in the logs of the build (Stored in RAM)
Search Jenkins Docs: Search in the Jenkins Documentation
Search Plugin Docs: Search in the Jenkins Plugins Documentation
Search Discussion: Search in the Reddit and Discourse Discussions

Deterministic

Get Workspace Tree: Get the tree of the workspace
Get Workspace File: Get a specific file of the workspace
Get Job File: Get the Job file (config.xml, build.xml, jenkinsfile)
Get Diff File: Get the diff of a specific file

Here you can find the link of the repository of the plugin → link:github url[AI Chatbot to Guide User Workflow Repository]

I’m very excited to create a plugin which can help all the Jenkins users and I would also be really happy to have your feedback.

Talk soon!

Meet Vatsal Verma – GSoC 2026 Contributor Working on Retooling Jenkins.io Web Success Stories

2026-05-26T08:43:08+00:00

Hello everyone!

I’m Vatsal Verma, a final-year student and a Google Summer of Code 2026 contributor with Jenkins. This summer, I’ll be working on Retool jenkins.io website Success Stories which aims to modernize the tech stack, improving the submission workflow, and enhancing the overall UI/UX experience of the website.

Project Description

This project aims to migrate the Jenkins.io Success Stories website from Gatsby to Vite, enabling faster builds, improved developer experience, and better performance. It focuses on modernizing the UI/UX with a responsive, accessible, and user-centric design. A key objective is redesigning the story submission workflow by moving from Decap/Netlify CMS to a GitHub Actions–based workflow, allowing structured, automated, and scalable content contributions.

This transition will also involve refining and standardizing YAML-based content files for better consistency, validation, and maintainability. Overall, the project enhances performance, scalability, and contributor experience while aligning the platform with modern web development practices.

What I did in the Community Bonding Period?

Joined the Jenkins GSoC onboarding and introductory call with mentors and organization admins.
Attended mentor meetings to discuss project scope, ideas, and implementation plans.
Set up the local development environment by forking the jenkins-infra/stories repository and configuring a dedicated gsoc-2026-revamp branch for development.
Discussed the story submission workflow and GitHub Actions-based approach for handling user-story submissions.
Designed and proposed a new UI for the project, collected mentor feedback, and iterated on the designs accordingly.
Explored the integration of the Vite SSG plugin in the project to improve performance, scalability, and static page generation for story routes.

What lies ahead (Coding Period)?

Begin the migration of the stories.jenkins.io platform from Gatsby to a Vite + React based architecture to improve maintainability, performance, and developer experience.
Refactor existing components and routing logic while replacing Gatsby-specific APIs and the GraphQL data layer with a lightweight YAML/JSON based approach.
Work on refining and standardizing the YAML structure used across existing stories to improve consistency and maintainability.
Design and implement the new story submission workflow, including a guided submission interface, live YAML preview, and automated GitHub Actions based processing.
Continue iterating on the proposed UI/UX redesign for the platform, focusing on responsiveness, accessibility, filtering, navigation, and overall user experience.
Add and improve repository tooling, including ESLint, Prettier, CI workflows, validation checks, and contributor-focused documentation to ensure long-term maintainability.

Future Plans

My future plans are to continue contributing to Jenkins and stay actively engaged with the community. I also want to help new contributors get started with this organization and open source in general. Being part of this community has taught me a lot, and I believe there is still so much more to learn and explore.

Acknowledgements

I would like to thank my mentors, Kris Stern, Rajiv Singh, Chamod Shehanka Perera, and the community for giving me this opportunity. I am excited to learn, contribute, and share my experience with others.

Follow Along

You can contact me:

Excited to contribute to Jenkins and collaborate with the community throughout the summer!

GSoC 2026 Community Bonding Period - Plugin Modernizer Stats Visualization

2026-05-26T08:43:08+00:00

Hey everyone! Myself Pratik Mane, a final year student at Vishwakarma Institute of Technology, Pune (India) and currently an intern at Red Hat. It’s been a wonderful experience getting involved with the Jenkins community over the past few weeks and I’m thrilled to be working on this project with an amazing team of mentors.

About the Project
Why is This Project Important?
What I Did in the Community Bonding Period
What Lies Ahead (Coding Period)
Acknowledgements
Useful Links

About the Project

The Plugin Modernizer Tool automates the modernization of Jenkins plugins using OpenRewrite recipes, creating pull requests with the results. As part of GSoC 2025, a metadata repository was established that stores raw modernization metadata all in JSON/CSV format.

My project, Plugin Modernizer Stats Visualization, aims to build a static visualization site that consumes this raw metadata, consolidates it into a structured format and presents dashboards alongside per-plugin/per-recipe report pages. For a detailed description of the project, please refer to the project page.

Why is This Project Important?

With over 400+ plugins already processed by the Plugin Modernizer Tool and more being added regularly, exploring the modernization results currently requires manually navigating between multiple directories for each plugin. There is no consolidated view or visual interface to understand the overall modernization health at a glance.

This project will help:

Plugin maintainers to see at a glance what their plugin needs to be modernized and what recipes have been applied.
Plugin modernizer authors to identify which recipes are working well and which need attention or fixes.
New contributors to lower the barrier to find plugins that need help, answering the question "where should I start ?"
The infra team to measure and communicate the impact of the modernization effort to the broader community.

What I Did in the Community Bonding Period

Architecture decisions with the Infra Team: I attended the Jenkins Infrastructure team meeting where we finalized the deployment architecture for the project. The original plan to publish data to reports.jenkins.io was revised instead, we will use GitHub Actions as our ETL pipeline and GitHub Pages to serve the aggregated data. This gives us full autonomy, a shorter feedback loop and no dependency on trusted.ci credentials.

Environment setup and prototype refinement: I set up my local development environment and created a small prototype (a temporary static UI that fetches data from the metadata repository and presents dashboards, per-plugin reports and per-recipe detail pages).
Community introduction: I drafted and sent an introduction email to the Jenkins Developer Mailing List to introduce the team, explain the project and solicit feedback from the community on what metrics and features would be most valuable.
Planning and scheduling: I worked closely with my mentors to refine the project phases, discuss data schema decisions and create a detailed plan for the coding period. We discussed the consolidation script design, the report.json structure and how the UI will consume the data.
Studying the ecosystem: I explored the existing jenkins-io-components library to understand which shared UI components (navbar, footer, etc) I can reuse and studied stats.jenkins.io for UI/UX alignment with the Jenkins visual ecosystem.
Communication is key: I attended Weekly sync project meetings & gsoc office hours with mentors, org admins and other gsoc contributors. One of the most valuable lessons from this bonding period staying transparent with mentors about decisions, progress and blockers.

What Lies Ahead (Coding Period)

The coding period is structured into five phases:

Phase 1 : Data Pipeline (ETL): A GitHub Actions workflow in metadata-plugin-modernizer that validates the raw data, runs a Python consolidation script to produce a single report.json and deploys it via GitHub Pages. This gives the UI a single, stable URL to fetch all aggregated modernization data.
Phase 2 : Dashboard (Home Page): Summary stat cards, migration status breakdown (donut chart), top 10 recipe performance (stacked bar), migration timeline trend, tag distribution and recipes with most failures.
Phase 3 : Plugin List & Per Plugin Reports: A virtualized, searchable, filterable table of all 400+ plugins with per-plugin detail pages showing migration timelines, recipe breakdowns, PR history and failure details.
Phase 4 : Recipe List & Per Recipe Reports: A table of all recipes with success/failure rates and per-recipe detail pages showing application trends and affected plugins.
Phase 5 : Stability & Documentation: Comprehensive testing, developer documentation and a final blog post.

The tech stack includes Vite 8 + React 19 + TypeScript, Material UI, Apache ECharts for charts and GitHub Actions + GitHub Pages for CI/CD and hosting.

I am excited to start coding and bring visibility to the amazing modernization work happening across the Jenkins ecosystem!

Acknowledgements

I would like to thank my mentors Valentin Delaye, Kris Stern, Sridhar Sivakumar and Raunak Madan for their guidance, encouragement and time. I would also like to thank the Jenkins Infrastructure team for their help in finalizing the deployment architecture.

This is a continuation of the work started by Sridhar Sivakumar in GSoC 2024 Using OpenRewrite Recipes for Plugin Modernization, improved by Raunak Madan in GSoC 2025 Improving Plugin Modernizer and I am grateful to have them as my mentors for this project.

Special thanks to the Jenkins community for being welcoming and supportive. I look forward to contributing throughout the summer and beyond also…

Useful Links

Plugin of the Month – May 2026: Coverage Plugin

2026-05-26T08:43:08+00:00

Welcome back to the Plugin of the Month series, where we highlight useful and impactful plugins from the Jenkins ecosystem.

For May 2026, we’re featuring the Coverage Plugin.

Quality assurance is a pillar of modern CI/CD. Knowing how much of your code is actually tested—and how effectively those tests find bugs is crucial for maintaining a healthy codebase. This month, we are highlighting the Coverage Plugin, a comprehensive solution for collecting, aggregating, and visualizing code and mutation coverage reports in Jenkins.

What is the Coverage Plugin?

The Coverage Plugin is the modern successor to several older, format-specific coverage plugins. Instead of installing a different plugin for every language in your stack, the Coverage Plugin provides a unified object model and a sleek UI to handle a wide variety of report formats.

Whether you are measuring line coverage with JaCoCo or mutation density with PIT, this plugin brings all that data into a single, high-level overview within your Jenkins dashboard.

Supported Formats

One of the strongest selling points of this plugin is its versatility. Out of the box, it supports an extensive list of report formats across various ecosystems:

Java: JaCoCo, OpenClover, JUnit, and PIT (Mutation Coverage).
Node: Cobertura
Go: Go Coverage results.
C#/.NET: OpenCover, NUnit
Embedded/Safety Critical: VectorCAST (including MC/DC, Function, and Function Call coverage).
Testing Frameworks: JUnit, NUnit, and XUnit.
Static Analysis: PMD software metrics (via a patched version of PMD).

Key Features

1. Unified Visualization

The plugin provides beautiful, interactive charts that track coverage trends over time. You can see at a glance whether your team is improving their test suite or if technical debt is creeping in.

2. Detailed Source Code View

It doesn’t just show percentages. You can drill down into specific files to see exactly which lines of code are covered (green) and which are missed (red), allowing developers to pinpoint gaps without leaving the Jenkins UI.

3. Quality Gates

You can define "Quality Gates" in your Pipeline. For example, you can configure the build to fail or become unstable if the overall coverage drops below a certain percentage, or if a specific pull request decreases the coverage by more than 1%.

4. Mutation Coverage Support

Beyond standard code coverage, the plugin supports PIT (Pitest). Mutation coverage tests the effectiveness of your tests by injecting faults into your code and seeing if your tests catch them. This provides a much deeper look into the reliability of your test suite.

Getting Started in a Pipeline

Integrating the Coverage Plugin into your Jenkinsfile is straightforward. Here is a simple snippet for a Java project with Maven using JaCoCo:

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        // Run your tests (e.g. Maven with JaCoCo)
        sh './mvnw clean verify'
      }
    }
    post {
      always {
        // Record coverage results
        recordCoverage(tools: [[parser: 'JACOCO', pattern: '/target/site/jacoco/jacoco.xml']])
      }
    }
  }
}

Contribute to the Ecosystem

The Jenkins community thrives on contribution. If your favorite coverage tool is not yet supported, the Coverage Plugin is built on a highly extensible Coverage Model. The maintainers welcome pull requests to add new parsers and features.

Explore the plugin today on the Jenkins Plugin Site and start improving your project’s transparency and quality!

Java JVM Updates and Memory Improvements in Jenkins

2026-05-26T08:43:08+00:00

In this post, we share our experience upgrading Jenkins from Java 17 to Java 21 and the impact this had on memory usage. After the move, we observed a reduction in out-of-the-field memory consumption from a monthly mean of 33–34 GB down to 28 GB. This improvement helped us reduce operational pressure and improve overall efficiency in our Jenkins environment.

Why we upgraded to Java 21

Java 17 served us well as a stable long-term support release, but as part of our ongoing platform modernization, we evaluated Java 21 for Jenkins. Our goals were simple:

benefit from the latest JVM performance improvements
reduce memory footprint
follow the platform recommendation

Java upgrades in production systems are never just about version numbers. They are about measurable operational outcomes. For us, memory usage was one of the most important signals.

What we observed

After moving from Java 17 to Java 21, we tracked memory usage in our production environment and compared the results over time. We made use of the Jenkins monitoring plugin based on Java melody.

The result was clear:

Before the upgrade: monthly mean memory usage of roughly 33–34 GB
After the upgrade: monthly mean memory usage of roughly 28 GB

That is a meaningful reduction of approximately 5–6 GB, or around 15–18% depending on the baseline.

Why memory improved

We did not make a single code-level change to achieve this reduction. The main driver was the JVM change itself.

Java 21 includes a number of runtime and garbage collection improvements that can positively affect memory behavior, especially in long-running server applications like Jenkins. While the exact impact depends on workload and configuration, the following areas are commonly relevant:

improved garbage collection behavior
runtime optimizations in the JVM

In our case, the upgrade improved the memory usage in our production environment significantly.

Preparation for bigger updates

Measure before and after. Establish a baseline with monitoring data before the upgrade, then compare metrics after the upgrade to validate improvements.

Recommendation

If you are currently running Jenkins on Java 17, it is worth your time to evaluate the latest LTS update and Java 21. You may see improvements in performance, stability, and memory efficiency, depending on your workload and configuration.

Conclusion

Upgrading from Java 17 to Java 21 delivered a noticeable improvement in Jenkins memory usage for our environment. We saw a reduction from 33–34 GB to a monthly mean of 28 GB without requiring application-level changes.

System information

more than 10000 daily builds
more than 1000 active users
more than 100 connected agents

Gear Up for Google Summer of Code (GSoC) 2026 with Jenkins

2026-05-26T08:43:08+00:00

We are thrilled to announce that the Jenkins project has been allotted 5 slots in Google Summer of Code (GSoC) 2026 program! This is an incredible opportunity for aspiring developers to contribute to one of the most widely used open-source automation servers in the world.

The 5 selected projects for GSoC 2026 are:

AI Chatbot to Guide User Workflow with Daniele Caldarigi as the GSoC contributor - Helping users navigate Jenkins with smart, automated assistance.
Continue AI-Powered Chatbot for Quick Access to Jenkins Resources with Mallikarjun G D as the GSoC contributor - Ongoing modernization of the Jenkins documentation retrieval experience.
Jenkins email notifications using Outlook SMTP with OAuth with Mohammed Faheem as the GSoC contributor - Enhancing Jenkins email notifications with secure Outlook SMTP integration.
Plugin Modernizer Stats Visualization with Pratik Mane as the GSoC contributor - Visualizing plugin modernization efforts with insightful statistics and trends.
Retool jenkins.io website Success Stories with Vatsal Verma as the GSoC contributor - Showcasing inspiring success stories on the jenkins.io website to motivate and guide users in their Jenkins journey.

These projects were selected from a pool of exciting proposals that aim to enhance the Jenkins ecosystem and improve the user experience. Each project will be mentored by experienced members of the Jenkins community, providing guidance and support throughout the summer.

We would like to extend our heartfelt congratulations to the selected contributors and express our gratitude to all the candidates who took the time to submit their proposals. Your enthusiasm and dedication to open source are what make the Jenkins community so vibrant and innovative.

We encourage everyone to follow the progress of these projects and support the contributors as they embark on their GSoC journey. Stay tuned for updates and insights from the contributors as they work on their projects over the summer!

Introducing the Secret Guard Plugin

2026-05-26T08:43:08+00:00

Hardcoded secrets still show up in Jenkins for very ordinary reasons.

A token is pasted into a job field during a quick test. A webhook URL with a secret query parameter stays in config.xml. An inline Pipeline header works once and is never revisited. These cases are easy to introduce and easy to overlook.

Once a secret is stored in job configuration or a Jenkinsfile, it becomes harder to rotate and easier to expose through exports, backups, logs, or screenshots.

The Secret Guard Plugin was created to help Jenkins administrators and job authors catch those patterns earlier.

What it checks

Secret Guard is a Jenkins plugin that checks Jenkins jobs and Pipeline definitions for hardcoded secret leakage risks.

It scans common high-risk locations such as:

Job config.xml
inline Pipeline scripts
Pipeline-from-SCM Jenkinsfiles when lightweight SCM access is available
multibranch Pipeline Jenkinsfiles when lightweight SCM access is available
parameter default values
environment variable definitions
command content such as sh, bat, powershell, and HTTP-style request usage

It can be used in several practical ways:

save-time enforcement for job configuration changes
build-time scanning
job-level Scan Now
global Scan All Jobs

The plugin stores masked results only, so administrators can review findings without persisting raw secret values in plugin reports.

The global Secret Guard page gives administrators a single place to review the latest scan results and run an on-demand scan across jobs.

A simple example

A common case is a Pipeline that embeds a token directly in an environment variable or HTTP header:

pipeline {
    agent any
    environment {
        API_TOKEN = 'ghp_012345678901234567890123456789012345'
    }
    stages {
        stage('Call API') {
            steps {
                sh "curl -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.abc123456789.def123456789' https://example.invalid"
            }
        }
    }
}

The safer pattern is to store the secret in Jenkins Credentials and inject it only at runtime:

pipeline {
    agent any
    stages {
        stage('Call API') {
            steps {
                withCredentials([string(credentialsId: 'api-token', variable: 'API_TOKEN')]) {
                    sh 'curl -H "Authorization: Bearer $API_TOKEN" https://example.invalid'
                }
            }
        }
    }
}

This is the kind of issue Secret Guard is designed to catch with deterministic rules rather than broad inference.

Why the scope is narrow

Secret Guard is intentionally narrow in scope.

It does not try to be a general-purpose governance platform or a generic code-quality tool. Instead, it focuses on recurring high-confidence secret leakage patterns in Jenkins configuration and Pipeline usage. That keeps the plugin easier to reason about and reduces noise from overly aggressive heuristics.

For teams that want to adopt it gradually, the plugin supports multiple enforcement modes:

AUDIT records findings without blocking
WARN allows the operation but surfaces the risk
BLOCK prevents unexempted findings at or above the configured threshold

This makes it possible to start with visibility and move toward stricter enforcement when teams are ready.

Learn more

Plugin site: Secret Guard Plugin
Source code: jenkinsci/secret-guard-plugin

Feedback and contributions are welcome.

Jenkins 2.562 and 2.555.2: Signed by LF Open Source, LLC

2026-05-26T08:43:08+00:00

Beginning April 28, 2026 with Jenkins weekly 2.562, the MSI installer is signed using the Microsoft Artifact Signing Service. The installer is signed by LF Open Source, LLC, courtesy of the Linux Foundation. The same change will be made in Jenkins LTS 2.555.2 beginning May 13, 2026.

In the transition period, there are some changes to the installation process. We hope that these changes are temporary while the installer’s reputation develops in Microsoft Defender SmartScreen.

Windows Edge - infrequently downloaded

Windows Edge, the default browser on Microsoft Windows, is integrated with Windows Defender SmartScreen. That integration causes new installers and new applications to be flagged as "infrequently downloaded".

Windows administrators that download the Jenkins installer with Microsoft Edge will need to click the "Keep anyway" button until Windows Defender SmartScreen decides the Jenkins MSI installer has enough reputation.

The Windows Edge dialog looks like this:

Windows Defender SmartScreen

When the MSI installer is run, Windows displays the SmartScreen prompt that says:

Microsoft Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.

— Microsoft Defender SmartScreen

The dialog looks like this:

Click the "More info" link and that will change the dialog to display the publisher of the signed MSI file. The publisher is "LF Open Source, LLC".

The dialog looks like this:

Press the "Run anyway" button and the MSI installer will run.

Frequently Asked Questions

Why change the MSI signing?

The previous code signing certificate expires May 16, 2026. An unsigned MSI installer has an even worse experience for users than the experience with Windows Defender SmartScreen.

Why use LF Open Source, LLC?

The Linux Foundation has already pioneered the MSI installer signing process through their work with the NodeJS Foundation. We were able to use their experiences to quickly revise our MSI installer signing to use the same techniques used by the NodeJS Foundation.

We interact frequently with the Linux Foundation because they host the Jira issue tracker for the Jenkins project. Those interactions continue to help the Jenkins project.

The Linux Foundation is the parent organization of the Continuous Delivery Foundation. The Continuous Delivery Foundation is the parent organization of the Jenkins project and holds its intellectual property.

Why not purchase an extended validation code signing certificate?

Extended validation certificates require a secure physical storage device or they require reliance on the code signing service of the certificate prvider. We rarely interact with the certificate providers and find it difficult when we interact with them. They are accustomed to working with corporations, not open source projects. Open source projects are not their primary income source and are not their target market.

Which operating systems are affected?

All supported versions of Windows are affected.

Supporting Open Source Maintainers: A German Petition for Better Legal Frameworks

2026-05-26T08:43:08+00:00

Open source software, as Jenkins, is the foundation of modern software development. Contributors maintain plugins, review pull requests, fix security issues, and support users, often alongside their regular jobs.

Many of these contributions happen in what is often called “Ehrenamt” (voluntary work), especially in Germany. However, the work done by thousands of volunteers for this goal is not recognized in Germany as volunteering, neither fiscally nor in terms of funding.

A Petition Addressing German Legislation

A German initiative is raising awareness for this challenge and calling for improvements in the legal and structural framework for open source contributors:

Petition: Recognition of Work on Open-Source as Volunteering in Germany

The goal of this petition is to encourage German legislators to improve the current situation for open source maintainers. It highlights that open source has become critical digital infrastructure, yet the people maintaining it often lack proper recognition and supportive legal conditions.

While the initiative is focused on Germany, its message resonates far beyond national borders.

Why This Matters for Jenkins

Jenkins is a community-driven project.

From core maintainers to plugin authors, documentation writers, and community organizers, Jenkins exists because people contribute their time and knowledge.

At the Jenkins Contributor Summit and many community discussions, one theme comes up repeatedly:

How do we make open source contribution more sustainable?

Maintainers face increasing challenges:

Growing number of contributions and pull requests
Rising expectations around security and quality
Limited time and resources

These challenges are not unique to Jenkins, they affect the entire open source ecosystem.

German Contributors in the Jenkins Community

Jenkins has a strong and active group of contributors from Germany.

This is also reflected in the project’s leadership and governance. With contributors like Alex Brandes and Daniel Krämer serving on the Jenkins Governance Board, and roles such as the Events Officer Stefan Spieker being represented from Germany, the German open source community plays an important role in shaping Jenkins.

Like many others in the ecosystem, these contributors invest significant time into maintaining and evolving Jenkins, often alongside their regular professional responsibilities.

This makes the topic of better legal and structural support for open source maintainers especially relevant.

A Shared Responsibility

Open source is not just a development model, it is shared infrastructure.

Companies, public institutions, and individuals all rely on projects like Jenkins. Supporting maintainers is therefore not only a community concern, but also a topic for policymakers.

Initiatives like this petition aim to bring open source sustainability into legislative discussions and improve the framework conditions for contributors.

Get Involved

If you want to support this initiative, you can learn more and sign the petition here:

Petition for Open Source Maintainers

Looking Ahead

The Jenkins community continues to evolve, and so do the challenges around maintaining such a large ecosystem.

By supporting initiatives like this, we can help improve the framework conditions for contributors, both within Jenkins and across the broader open source world.

Because in the end, open source is built by people, and it depends on us to support them!

Plugin of the Month – April 2026: Pipeline Graph View

2026-05-26T08:43:08+00:00

Welcome back to the Plugin of the Month series, where we highlight useful and impactful plugins from the Jenkins ecosystem.

For April 2026, we’re featuring the Pipeline Graph View Plugin.

A Modern Pipeline Visualization

The Pipeline Graph View plugin provides a clean and modern visualization of Jenkins pipelines directly in the standard Jenkins UI.

It is designed to give users a clear overview of pipeline stages and their execution flow, without requiring a separate interface or additional UI layer.

If you’ve used Blue Ocean in the past, this might feel familiar, but with an important difference.

The Successor to Blue Ocean

As many in the Jenkins community are aware, Blue Ocean has been deprecated.

While it introduced a modern and intuitive way to visualize pipelines, maintaining a separate UI stack proved challenging in the long run.

The Pipeline Graph View plugin takes a different approach:

It integrates directly into the existing Jenkins UI
It focuses specifically on pipeline visualization
It avoids the overhead of maintaining a full alternative interface

This makes it a natural and lightweight successor for users looking for a modern pipeline view without switching contexts.

Why It Matters

Understanding pipeline execution is essential for debugging, optimization, and daily development workflows.

The Pipeline Graph View plugin helps by:

Providing a clear visual representation of pipeline stages
Making it easier to identify failures and bottlenecks
Improving the overall usability of Jenkins pipelines
Keeping everything within the familiar Jenkins interface

It brings back the visual clarity many users appreciated in Blue Ocean, while aligning with the direction of Jenkins.

If you work in a rather complex pipeline environment, this plugin can help you to faster find the stage that is interesting for you and to understand the flow of your pipeline. You can simply use the search function to find the stage you are looking for and then click on it to jump to the stage details.

Seamless Integration

One of the biggest advantages of this plugin is its seamless integration.

There’s no need to:

Switch to a different UI
Maintain a separate plugin ecosystem
Relearn how Jenkins works

You simply get an improved pipeline visualization experience where you already work.

Interactive Features

There is a small video to show some of the interactive features of the plugin:

Looking Ahead

The Pipeline Graph View plugin is a great example of how the Jenkins community continues to evolve the user experience while staying true to the platform’s strengths.

If you’re still relying on older visualization tools or missing features from Blue Ocean, this plugin is definitely worth exploring.

Stay tuned for next month’s Plugin of the Month, and feel free to suggest plugins you’d like to see featured!

JetBrains Report Highlights Jenkins as a Popular CI/CD Tool in 2026

2026-05-26T08:43:08+00:00

A recent JetBrains blog post, "Best CI/CD Tools for 2026: What the Data Actually Shows", provides an overview of CI/CD tool adoption and trends. According to the report, Jenkins continues to play a major role in the ecosystem, with a 28% adoption rate, ranking just behind GitHub Actions. This highlights that Jenkins remains a widely used and trusted solution across organizations of all sizes.

The article highlights that while newer tools focus on ease of use, Jenkins’ enduring value lies in its unparalleled autonomy and extensibility. Here are the key strengths of Jenkins as identified in the report:

1. Flexibility and Control

The blog emphasizes that Jenkins is the premier choice for teams that need "full control over infrastructure and data." Unlike SaaS-based CI tools, Jenkins allows organizations to own their entire environment, which is a critical requirement for:

Strict Security & Compliance: Organizations with sensitive data that cannot leave private infrastructure.
Self-Hosting: Teams that prefer to manage their own compute resources to avoid the "black box" nature of cloud-native CI.

2. A Strong and Open Ecosystem

Even in 2026, Jenkins' ecosystem remains its greatest asset. The report highlights that:

Universal Integration: It can integrate with almost any tool in the software development lifecycle, from legacy version control systems to modern cloud providers.
Custom Workflows: Because of its open-source nature and thousands of plugins, it supports highly specialized or "bespoke" workflows that standard commercial tools might not accommodate.

3. Resilience in "Complex and Legacy" Environments

The article categorizes Jenkins as the "Best fit" for complex or legacy setups. While newer tools excel at "greenfield" projects (starting from scratch), Jenkins is praised for its ability to:

Manage "long-lived" setups that have evolved over years.
Support diverse, multi-platform environments (Windows, Linux, macOS).
Handle "heavy" pipelines that require professional DevOps expertise to orchestrate.

4. Open Source and Cost Transparency

As an open-source tool, Jenkins offers a significant financial advantage: no licensing fees. For large-scale enterprises with the engineering talent to maintain it, Jenkins provides a way to scale without the per-user or per-minute costs associated with commercial platforms like TeamCity or CircleCI.

5. Mature Pipeline-as-Code

The blog acknowledges Jenkins’ commitment to modern practices through the Jenkinsfile. This allows teams to define build, test, and deployment logic as code, ensuring that even this "venerable" tool remains compatible with GitOps and modern version-control-driven development.

A Balanced Perspective

The JetBrains report also notes that Jenkins typically requires more operational effort compared to fully managed CI/CD services. This is an important consideration: Jenkins provides flexibility and control, but it also assumes that teams are willing to invest in operating and maintaining their setup. For many organizations, this trade-off is intentional.

Summary

The report reinforces what many in the community already know: Jenkins continues to be a reliable and flexible CI/CD platform that adapts to a wide variety of use cases.

Its strength lies not in being the simplest tool, but in being one of the most adaptable and extensible. As the CI/CD landscape evolves, Jenkins remains a strong choice for teams that value:

Control over their infrastructure
Flexibility in their workflows
A mature and active open source ecosystem

And most importantly, it continues to be shaped by the contributions of its global community.

JetBrains has long supported open source communities, including Jenkins. Many Jenkins contributors benefit from free JetBrains IDE licenses, which help them build, maintain, and improve the project.

Redesigned Credentials in Jenkins

2026-05-26T08:43:08+00:00

We’re introducing a fresh new look for the Credentials plugin, one of the most widely used Jenkins plugins and the foundation for securely storing and supplying credentials across Jenkins.

So what’s new?

Integration with the new Manage Jenkins UI

This update brings the plugin into Jenkins’ experimental Manage Jenkins UI, aligning credential management with the broader interface modernization underway in Jenkins core. Jenkins has been rolling out an experimental Manage Jenkins layout alongside a wider redesign focused on clarity, accessibility, and reducing older navigation patterns, and the Credentials plugin now joins that effort with its own refreshed experience.

Goodbye tables

The old table-based layout has been replaced with card-based views that are much easier to scan and navigate. Information is presented more clearly, with less visual clutter and a stronger focus on the actions people need.

Wizards and dialogs

Creating credentials now happens through guided wizards that make each step clearer and easier to follow. Actions such as editing, moving, and deleting credentials are now handled in dialogs, keeping users in context instead of sending them through a chain of separate pages.

Available now 🚀

The update is available now for users on Jenkins 2.541.1 and later.

If you want to get involved in the UI and UX discussions of Jenkins join the User Experience SIG.

Take advantage of new components and patterns in your plugin via the Design Library.

You can watch our monthly meetings on YouTube and you can view in-progress work on GitHub.

Introducing the Chinese Workday Plugin

2026-05-26T08:43:08+00:00

Many Jenkins jobs depend on business calendars.

For teams in China, that can be difficult to model with a simple weekday/weekend check. A weekday is not always a workday, and a weekend is not always a holiday. Chinese statutory holidays and make-up workdays change every year, so Pipeline logic often needs more than basic date rules.

The Chinese Workday Plugin was created to support that use case in Jenkins.

What the plugin provides

The plugin adds Pipeline steps for Chinese workday checks:

isChineseWorkday(…)
isChineseHoliday(…)
chineseWorkdaySupportedYears()

It also lets administrators add or override calendar data in:

Manage Jenkins → System → Chinese Workday

This makes it possible to keep holiday calendar logic in one place instead of repeating it across Jenkinsfiles.

Example

One common use case is to run a stage only on a Chinese workday:

pipeline {
    agent any
    stages {
        stage('Release') {
            when {
                expression {
                    isChineseWorkday()
                }
            }
            steps {
                echo 'Release runs only on a Chinese workday.'
            }
        }
    }
}

Why it helps

Without dedicated support, teams often duplicate holiday logic in Pipelines or rely on weekday-only checks. That can cause jobs to run during holidays or skip make-up workdays.

The plugin keeps those rules centralized and makes Pipeline behavior easier to understand.

Learn more

Plugin site: plugins.jenkins.io/chinese-workday
Source code: github.com/jenkinsci/chinese-workday-plugin

Feedback and contributions are welcome.

Revamped Build Monitor plugin

2026-05-26T08:43:08+00:00

We’re excited to announce a major update to the Build Monitor plugin - a complete redesign that refreshes its big-screen view with a cleaner, more modern interface for following build statuses.

So what’s new?

Rewritten and redesigned

Originally created for Jenkins 1 and powered by AngularJS, the plugin has now been completely rebuilt in React. The redesign uses components from the Jenkins Design Library and aligns with the new Jenkins interface, delivering a cleaner look, smoother navigation, theme support, and a more maintainable foundation for future development.

Customization

Build Monitor is now theme-aware - allowing you to match its appearance to your Jenkins theme.

Check out some of the themes available for Jenkins:

Dark theme - A sleek, modern look that’s easy on the eyes.
Solarized theme - Ethan Schoonover’s beloved, balanced theme returns with a fresh release for Jenkins.
Catppuccin theme - A soothing pastel theme for Jenkins.
Chocolate theme - Indulge your Jenkins in rich, dark tones with golden highlights for a refined and elegant developer experience.
Nord theme - A clear, uncluttered, and elegant design to achieve undisturbed focus and excellent readability.

Build Monitor now also supports Customizable Header plugin, allowing you to customise the header shown in the monitor.

And more!

Build Monitor now displays the view description and introduces several long-requested improvements, including customizable auto-refresh, user avatars, and colorful badges, making the dashboard more informative and easier to scan at a glance.

Available now 🚀

The update is available now for users on Jenkins 2.516.3 and later.

If you want to get involved in the UI and UX discussions of Jenkins join the User Experience SIG.

Take advantage of new components and patterns in your plugin via the Design Library.

You can watch our monthly meetings on YouTube and you can view in-progress work on GitHub.

Introducing the Jenkins Plugin of the Month

2026-05-26T08:43:08+00:00

Introducing the Jenkins Plugin of the Month

The Jenkins ecosystem thrives because of its plugins.

With more than two thousand plugins available, Jenkins users can extend their automation platform in countless ways—integrating with tools, improving security, enhancing the user interface, or supporting new development workflows. Behind each plugin are maintainers and contributors who invest their time to build and support these extensions.

To highlight this work and help users discover useful functionality, we are introducing a new initiative on the Jenkins blog:

Plugin of the Month

Each month, we will feature a Plugin of the Month.

The goal is to showcase plugins that provide valuable functionality for Jenkins users, highlight the work of their maintainers, and help the community discover capabilities they may not yet know about.

Sometimes the featured plugin will be widely used but underappreciated. Other times it may be a newer plugin that solves an interesting problem. In all cases, the focus is on highlighting contributions that strengthen the Jenkins ecosystem.

If you maintain or use a plugin that deserves more visibility, we welcome suggestions for future editions.

Plugin of the Month: OIDC Provider Plugin

Our first featured plugin is the OIDC Provider Plugin.

This plugin allows Jenkins to act as an OpenID Connect (OIDC) provider so that external systems can securely authenticate using identities issued by Jenkins.

Instead of storing long-lived credentials or secrets inside Jenkins pipelines, systems can request short-lived tokens using the OIDC standard. This significantly reduces the need to manage and rotate static secrets.

Why This Matters

Managing credentials and secrets in CI/CD pipelines can quickly become complex and risky. Long-lived access keys stored in configuration or credentials stores are a common attack vector.

By using OIDC-based authentication, Jenkins can issue short-lived identity tokens that external systems trust. This approach improves security while simplifying credential management.

This is especially useful when Jenkins pipelines interact with cloud providers such as:

Microsoft Azure
Google Cloud Platform (GCP)
Amazon Web Services (AWS)

Instead of storing cloud access keys in Jenkins, pipelines can authenticate using federated identity through OIDC.

The plugin is not limited to cloud providers. It can also be used to authenticate with internal services, such as a local Artifactory instance or other systems that support OIDC.

Reducing Secrets in Pipelines

One of the biggest advantages of this approach is the ability to reduce or eliminate stored secrets in Jenkins pipelines.

Benefits include:

No long-lived credentials stored in pipelines
Reduced secret management overhead
Short-lived tokens issued on demand
Better alignment with modern cloud security practices

Looking Ahead

The Jenkins plugin ecosystem is one of the project’s greatest strengths. With the new Plugin of the Month series, we hope to highlight the innovation and dedication that plugin maintainers bring to the community.

Stay tuned for next month’s featured plugin — and if you have a favorite plugin you think should be highlighted, let us know.

Together, we continue to grow and strengthen the Jenkins ecosystem.

Jenkins Contributor Summit: Officers View on the Present and Future

2026-05-26T08:43:08+00:00

The Present and the Future of Jenkins

This post continues the recap of the Jenkins Contributor Summit held in Brussels alongside FOSDEM. If you missed the first overview of the event, you can read it here:

Impressions from the Jenkins Contributor Summit in Brussels

While the first post focused on the atmosphere and discussions during the summit, this article highlights one of the key sessions of the day: “The Present and the Future – The Jenkins Officer’s View.” During this session, Jenkins project officers shared updates about the current state of the ecosystem and the work being done to keep Jenkins evolving.

Release Automation and Dependency Updates

Automation continues to play an important role in maintaining the health of the Jenkins ecosystem.

Currently, 673 plugins and 35 components are using automated releases. The adoption of this process has steadily grown over the past few years:

2023: 280 automated releases
2024: 580 automated releases
2025: 708 automated releases

At the same time, dependency management across the Jenkins organization has improved significantly. The introduction of Renovate across the jenkinsci GitHub organization allows maintainers to keep dependencies up to date automatically, reducing maintenance burden and improving overall security and stability.

Security: Continuous Improvements

Security remains a major focus for the Jenkins project.

Over the past several years, the Jenkins security team has continued to manage vulnerability disclosures and advisories for the ecosystem:

2022: 16 security advisories covering 297 tickets
2023: 17 advisories covering 212 tickets
2024: 11 advisories covering 57 tickets
2025: 12 advisories covering 82 tickets

Only two critical vulnerabilities were reported in 2025, both affecting plugins with relatively low usage.

Around 20% of vulnerabilities are reported directly by the Jenkins security team, demonstrating the proactive work being done to improve the security of the ecosystem.

Security research and education also remain an important mission for the project. Over the past years, Jenkins has collaborated with students and researchers:

2021: 4 master students from Luminy
2022: Valdes – 6-month internship
2023: Andrea – 3-month internship
2024: onboarding of Swapna Nanda
2025: 7 master students from Luminy

These collaborations have led to 5 findings being fixed and 30 findings being published without fixes, mostly affecting long-tail plugins that currently lack active maintainers.

Content Security Policy (CSP)

Another long-term effort discussed during the summit was the implementation of Content Security Policy (CSP) support in Jenkins.

This initiative has been evolving over several years:

August 2020 – first public draft PR demonstrating the concept
October 2021 – discussed during Hacktoberfest
July 2022 – broader involvement with Jenkins core and documentation
September 2022 – revisited during Hacktoberfest
End of 2024 – major progress supported by Alpha Omega funding
January 2026 – CSP support introduced as opt-in in Jenkins 2.539 / 2.541.1

This work aims to strengthen the browser security model of Jenkins while ensuring compatibility with the large plugin ecosystem.

User Experience Progress

User experience improvements have been gaining significant momentum.

The past year has been the biggest year yet for the Jenkins User Experience SIG, with:

86 merged pull requests
54 issues resolved
5 blog posts sharing progress and improvements

These efforts aim to gradually modernize the Jenkins interface and make the system easier to use for both new and experienced users.

Looking Ahead

The updates from the project officers demonstrated that Jenkins continues to evolve across multiple fronts: automation, security, infrastructure, and user experience.

Maintaining a project of this size requires sustained effort from contributors across the globe. The numbers shared during the summit highlight not only the scale of the Jenkins ecosystem, but also the steady progress being made to keep it secure, modern, and sustainable for the future.

Jenkins Contributor Awards 2026 - Nominations are Open

2026-05-26T08:43:08+00:00

The Jenkins community thrives because of its contributors.

Every day, maintainers, advocates, security researchers, and community members invest their time to improve Jenkins and support users around the world. The Jenkins Contributor Awards are our way of recognizing these efforts and celebrating the people who make the project stronger.

For 2026, the Jenkins awards are being hosted by the Continuous Delivery Foundation (CDF) alongside the broader CDF Community Awards.

Nominate Outstanding Contributors

Nominations are now open, and any contributor is eligible for recognition.

To ensure transparency and openness, nominations are being collected publicly through GitHub issues. This allows the community to see the nominations and celebrate contributors together.

Make sure to submit your nominations before the deadline on April 2, 2026.

Cast Your Vote

After nominations close, the community will have the opportunity to vote.

Voting opens on April 8 and runs until May 5, 2026. During this period, everyone in the community can participate by voting through the official Google Form, which will list all nominees and award categories.

This is your chance to help highlight the people who move Jenkins forward.

Jenkins Award Categories

You can nominate contributors in several Jenkins-specific categories:

Each category highlights a different kind of impact — from technical contributions and community advocacy to improving the security of the Jenkins ecosystem.

The winners will be officially announced at cdCon 2026, taking place May 18–20, 2026.

Additional CDF Community Awards

In addition to the Jenkins-specific awards, the Continuous Delivery Foundation also recognizes contributors across the broader CD ecosystem.

Categories include:

Top CDF Ambassador
Top CDF Contributor
Top CDF End User

If you know someone making an impact beyond Jenkins, consider nominating them as well.

For full details about all award categories and the nomination process, visit the CDF Awards page.

Celebrate the Community

Open source projects succeed because of the people behind them. The Jenkins Contributor Awards are a chance to highlight those efforts and say thank you.

If someone in the community inspired you this year — submit a nomination and help us celebrate their contributions.

Impressions from Jenkins Contributor Summit in Brussels

2026-05-26T08:43:08+00:00

Jenkins Contributor Summit 2026: A Personal Reflection

The Jenkins Contributor Summit in Brussels was a milestone for me.

Not just because contributors from across Europe and also from the United States came together in one place. But because it was the first time I had the privilege of moderating the event. Thanks a lot to Stephane Merle for the time keeping and Bruno Verachten for the planning and organization support.

Standing in front of a room full of long-time maintainers, officers, SIG leads, and community members is both humbling and inspiring. Many of us collaborate daily online, yet being physically in the same room changes the dynamic completely.

This summit reminded me that Jenkins is not just an automation server — it’s a living ecosystem shaped by people who care deeply about it.

Setting the Stage

We began by welcoming everyone and outlining the goals for the day.

As moderator, my role wasn’t to dominate discussions but to guide them with keeping conversations focused, making sure different voices were heard, and ensuring we stayed aligned with the broader objectives. Open source thrives on open discussion, but structure helps turn discussion into progress.

From the beginning, the atmosphere was collaborative and forward-looking.

The Present and the Future - Officer Perspectives

One of the core sessions focused on the present state and the year 2025 of Jenkins from the perspective of project officers.

We heard updates covering the year’s accomplishments, ongoing challenges, and strategic priorities from the officers’ point of view:

Infrastructure
Release processes
Documentation challenges and improvements
Events and community engagement
Security efforts

These perspectives grounded the summit in reality. Jenkins operates at global scale, and maintaining trust — in releases, infrastructure, and security — requires continuous effort behind the scenes.

It was a reminder that governance and operational work are just as critical as writing code.

There will be a separate blog post covering the officer updates in more detail, but I want to highlight the security update here.

Security and Bug Bounty Program

An important aspect worth highlighting is the sponsorship support from the European Commission. The funding, managed by YesWeHack as part of a structured Bug Bounty program, strengthens the security posture of Jenkins in a very concrete way. This kind of institutional support demonstrates that open source infrastructure like Jenkins is recognized as critical digital infrastructure. If you missed the blog post about the Bug Bounty program, you can find it here: Introducing the Jenkins Bug Bounty Program. A big thanks also to the security team for their ongoing efforts in this area and securing nice shirts for all contributors.

SIG Updates and Technical Direction

The Special Interest Groups shared progress and plans, particularly around User Experience and Platform topics.

The UX discussions highlighted how carefully the project must balance modernization with backward compatibility. Jenkins cannot simply reinvent itself overnight — it evolves incrementally, respecting the massive ecosystem built around it.

On the technical side, we discussed Java support, the challenges faced by community plugin maintainers, and the ongoing effort to modernize plugins at scale.

The session on plugin modernization and OpenRewrite stood out. Automating large-scale refactoring is essential for keeping the ecosystem healthy without overwhelming maintainers. Sustainability is not just about infrastructure, it’s also about reducing maintenance burden.

Interaction and Momentum

We made space for interaction — including brainstorming workshop ideas and identifying areas where deeper collaboration is needed.

Once contributors start exchanging ideas in person, momentum builds quickly. Topics ranged from AI fabricated Pull Requests to onboarding improvements and UX refinements.

The energy in the room was constructive. Disagreements were pragmatic rather than ideological. Everyone shared the same goal: ensuring Jenkins remains relevant and reliable.

I took a photo during one of the sessions, and it captures the spirit of the summit:

Advocacy and Community Building

We also talked about advocacy and outreach.

How do we attract new contributors? How do we support existing maintainers? How do we communicate innovations more effectively?

One recurring realization: Jenkins builds valuable improvements, but we don’t always communicate them clearly enough. Strengthening community outreach is essential for long-term growth.

Open Discussion and the “Headstand” Exercise

During the open discussion, we ran a structured “headstand” exercise to generate fresh ideas.

Instead of asking, “How do we achieve our goal?”

we deliberately flipped the challenge upside down and asked, “How could we guarantee the opposite?”

The Headstand

The concrete question we explored was:

How can we help maintainers spend as much time as possible with first-time contributors?

We brainstormed policies, tools, behaviors, and attitudes that would guarantee this outcome.

The answers were intentionally “bad” ideas:

Remove or neglect documentation
Avoid automation wherever possible
Make contribution guidelines unclear
Spending as much time as possible on manual feedback
Auto merge failing pull requests without feedback

By exaggerating the negative, we uncovered hidden assumptions about onboarding, mentorship, and process inefficiencies.

Flip It Back

We then inverted the ideas:

How could we make maintainers spend as little time as possible with first-time contributors?

Each “bad” idea was turned into its constructive opposite:

Improve documentation clarity and structure
Automate repetitive feedback and checks
Invest in contributor education and self-service resources
Make use of bots and tools to handle common issues

The exercise created clarity quickly. Instead of abstract discussions about “better onboarding,” we identified concrete improvement areas grounded in real maintainer experience.

Sometimes, thinking about how to fail is the fastest way to understand how to succeed.

Workshops: AI and UX

We closed with focused workshop discussions, including:

AI Slop: When Automation Creates More Noise Than Value

One topic that surfaced in our discussions — and that clearly extends beyond Jenkins — is the growing pressure on maintainers in what some call the AI slop.

GitHub recently described this phenomenon: contribution has never been easier. Opening issues, submitting pull requests, and now even generating code with AI tools can be done in minutes. The barrier to entry is low — which is great for accessibility — but the review burden remains high. This creates a paradox: more contributions can mean more noise, not necessarily more value. If you are curious about this topic, check out the GitHub blog post: Welcome to the eternal september of open source.

Practical UI/UX evolution steps

There was also a workshop focused on practical steps for evolving the Jenkins UI/UX. The challenge is how to modernize the user experience without alienating existing users or breaking plugins. One way to test changes is with the feature flag system, allowing gradual rollout and feedback collection. If you are curious what is already possible, see what is already available in your Jenkins instance.

Personal Reflections

For me personally, moderating the summit was a learning experience.

It required:

Managing time without suppressing energy
Encouraging quieter participants to speak
Navigating strong opinions constructively
Reading the room and adjusting pace

Most of all, it reinforced something I already knew but felt more strongly in Brussels:

Jenkins is sustained by people who show up.

The Contributor Summit wasn’t just a series of agenda items.

It was alignment.

It was trust-building.

It was shared responsibility.

And I’m grateful that this time, I got to help guide the conversation from the front of the room. Thanks to everyone who participated, shared their perspectives, and contributed to the discussions.

Jenkins accepted as mentoring org for Google Summer of Code (GSoC) 2026

2026-05-26T08:43:08+00:00

Jenkins Accepted to Google Summer of Code 2026 🎉

We are thrilled to announce that Jenkins has been accepted as a mentoring organization for Google Summer of Code (GSoC) 2026! This marks our tenth year participating in this prestigious program, and we are excited to continue welcoming new contributors into our vibrant open-source community.

Why GSoC Matters

Google Summer of Code is an outstanding opportunity for aspiring developers to gain hands-on experience in open-source software development. Participants work on real-world projects, collaborate closely with experienced mentors, and make meaningful contributions to the Jenkins ecosystem. We are committed to providing a supportive and inclusive environment for all GSoC participants, and we look forward to seeing another summer of fruitful contributions that will emerge from this year’s program.

Preparing Your Application

If you’re interested in applying, now is the perfect time to get started. We encourage all interested candidates to start preparing their applications and to join our upcoming webinars where we will discuss potential project ideas and provide guidance on the application process. Stay tuned for more details on how to get involved and make the most of this exciting opportunity!

What’s on the near horizon for GSoC candidates?

Review the information for contributors page for detailed application guidelines.
Join our webinars for a walk through of project ideas, the details of which will be made available over the coming days via our official communication channels. Recordings of these webinars will be made available after each session.
Use the official proposal template to structure and draft your project proposal.

We encourage you to start engaging with the community early, ask questions, and explore the available project ideas. The more familiar you are with Jenkins and its ecosystem, the stronger your proposal will be.

Refer to the GSoC timeline for a complete list of important dates.

Impressions from Jenkins Stand at FOSDEM Brussels

2026-05-26T08:43:08+00:00

Two Days Behind the Jenkins Booth at FOSDEM 2026

FOSDEM is always a blur. Two days, hundreds of conversations, one booth, and just enough coffee and beer to get through the weekend.

This year at FOSDEM 2026, I had the privilege of standing behind the Jenkins booth. If you’ve ever wondered what it’s like on the other side of the table at one of the busiest open source conferences in Europe — here’s a field report.

The Visitor Archetypes

After about 50 conversations, patterns emerge. By the end of day two, you can almost predict the opening line.

1. The “I Just Wanted to Say Thank You” Visitor

They don’t want stickers. They don’t want to debate YAML vs Groovy.

They just walk up and say:

“Hey, I’ve been using Jenkins for years. Thank you.”

Some run builds for research labs. Some ship medical devices. Some maintain internal tooling for companies you’ve definitely heard of.

They’ve been quietly relying on Jenkins for a decade or more. No drama. Just pipelines running at 2am.

These conversations are short — but they’re the ones you carry home.

2. The “Wait… Blue Ocean Is Being Deprecated?” Crowd

This one starts with excitement:

“I love Blue Ocean!”

And then we gently explain the status of Blue Ocean.

Cue visible surprise.

Blue Ocean was a bold experiment in rethinking the Jenkins UX. It brought modern pipeline visualization to a platform that predates most current frontend frameworks. But maintaining a parallel UI stack long-term is hard — especially in an open source project driven by volunteers.

The common reactions:

“Oh… I didn’t know.”

“What should I use instead?”

“Is there something new coming?”

Which leads directly to…

3. “Have You Heard of Pipeline Graph View?”

Short answer: probably not. Long answer: that’s part of the problem.

Pipeline Graph View is the modern, actively maintained visualization for Jenkins pipelines. It’s lighter, integrated into the main UI direction, and not trying to be an entire alternative universe.

Yet over two days, most people who loved Blue Ocean had never heard of it.

This is the classic open source paradox:

We built the thing. We shipped the thing. But communicating the thing? That’s harder than merging the PR.

If you’re still associating Jenkins pipeline visualization exclusively with Blue Ocean, it might be time for another look.

4. Groovy Pipeline Confessions

Some conversations begin in a whisper:

“I… may have abused scripted pipeline.”

We heard it all: 2,000-line Jenkinsfiles

Groovy is powerful. Maybe too powerful.

But here’s the interesting part: these weren’t complaints. They were confessions from people who pushed Jenkins to its limits — and sometimes beyond — because it let them.

Declarative pipelines helped. Shared libraries helped. But the raw flexibility of Groovy remains both Jenkins’ superpower and its chaos engine.

And we love you for using it creatively. Even if we gently recommend refactoring.

5. The Angry Butler Sticker Phenomenon

We brought stickers. Lots of stickers.

One clear winner:

It turns out that an anthropomorphic CI server expressing mild frustration is extremely relatable.

There’s something deeply honest about a slightly annoyed butler judging your broken build.

6. Our Neighbors: GitLab

Right next to us: GitLab.

You might expect rivalry vibes. Instead? It was refreshingly friendly.

We traded stickers. We compared notes on visitor questions. We laughed about shared CI/CD pain points.

At the booth level, it wasn’t “us vs them.” It was: “CI is hard. Solidarity.”

Open source ecosystems overlap more than marketing pages suggest. Many people run hybrid setups. Many teams experiment. The lines are blurrier than Twitter debates imply.

And honestly? The GitLab folks were pretty cool.

Everywhere AI

If FOSDEM 2026 had a background soundtrack, it would be:

“Does it use AI?”

Every hallway track, every devroom, every booth.

So yes — Jenkins conversations also drifted there.

Which made this especially relevant:

The Explain Errors Plugin

If you haven’t seen it yet, check out the Explain Errors Plugin.

The idea is simple: When your pipeline fails, you don’t just get a stack trace. You get help understanding it.

That’s the kind of AI integration that feels aligned with CI/CD: Practical. Contextual. Opt-in.

Not replacing engineers. Helping them get unstuck faster.

Behind the Booth: Learning the Ropes

A booth doesn’t run itself.

Before FOSDEM, I had no idea how much choreography is involved: sticker logistics, demo rotations, handling tough questions, knowing when to go deep and when to keep the line moving.

Huge thanks to Bruno Verachten and Stephane Merle for patiently teaching me how to operate the booth — from the practical details to the subtle art of engaging passersby without overwhelming them.

If I looked like I knew what I was doing, it’s because I had excellent teachers.

What Two Days Behind the Booth Teaches You

Jenkins is still everywhere.

Communication is as important as code. Special thanks go to everyone who stopped by to share their stories, ask questions, and give feedback.

Stickers matter more than you think.

Open source is powered by humans showing up in person.

FOSDEM compresses an entire year of GitHub issues into two days of real conversations.

And behind the booth, between sticker handoffs and pipeline debates, you’re reminded:

Jenkins isn’t just a server. It’s a community that keeps shipping.

See you next year.

Tuning Jenkins Java Settings For Responsiveness and Stability with Large Instances

2026-05-26T08:43:08+00:00

Hello, Jenkins Community!

As of Java 17, the JVM’s defaults have improved to the point where hand-tuned configurations often make performance worse rather than better.

The runtime now:

Detects container limits and sizes heaps/threads accordingly
Optimizes pause times automatically using real-time profiling
Allocates memory more efficiently
Uses G1GC by default, which is more predictable than older collectors

Using -XX:MaxRAMPercentage and -XX:InitialRAMPercentage settings instead of fixed -Xms and -Xmx has resulted in fewer GC pauses, better stability across different container sizes, and less memory pressure.

Understanding the Settings

Before diving into configuration, it’s important to understand what these JVM options do:

G1GC (Garbage First Garbage Collector): G1GC divides the heap into regions and collects garbage incrementally, designed to keep pause times predictable and low. It’s the default for Java 17+ and works well for heaps from 4GB to 40GB.
MaxRAMPercentage: Specifies what percentage of the container’s available memory should be used for the Java heap. Unlike fixed -Xmx, this automatically scales if the container is resized. A value of 60.0 means 60% of the container’s RAM becomes the max heap.
InitialRAMPercentage: Sets the initial heap size as a percentage of available memory. Starting smaller (20%) allows the heap to grow gradually, which can reduce pressure during startup and allow the GC to tune itself as workload patterns emerge.

Recommended Settings for Java 17, 21, and up

For Controllers (larger instances):

JAVA_OPTS="
  -XX:+UseG1GC
  -XX:MaxRAMPercentage=60.0
  -XX:InitialRAMPercentage=20.0
"

For Workers or smaller instances:

JAVA_OPTS="
  -XX:+UseG1GC
  -XX:MaxRAMPercentage=75.0
  -XX:InitialRAMPercentage=50.0
"

For controllers, the conservative 60% setting leaves room for OS buffers and native memory. Workers often tolerate higher heap percentages since they’re more isolated and less likely to have multiple memory-intensive processes.

For a more in depth analysis of what Jenkins does under the hood, view the original 2016 article here:

GC Tuning, the magic settings

Cloudbees also has an article here which is more up to date:

JVM Memory Settings Best Practice

Notes on Older Java Versions

If you still run Java 11 or earlier:

Use fixed heap sizing (-Xms / -Xmx), because container support varies and automatic scaling is unreliable.
Ensure -XX:+UseContainerSupport is set (it’s default in most builds, but verify).
Set both -Xms and -Xmx to the same value to avoid pauses from heap expansion.
Example for 8GB container: -Xms4G -Xmx4G -XX:+UseG1GC

Consider upgrading to Java 17+ if possible, as the memory management is substantially better.

Common Pitfalls and Anti-Patterns

Don’t set heap to 100% of container memory: The OS needs memory for buffers, caches, and native libraries. Leaving 30–40% for the OS prevents out-of-memory kills and improves overall performance.
Don’t mix fixed sizing with percentages: Using both -Xmx and -XX:MaxRAMPercentage creates confusion about which takes precedence. Choose one approach and stick with it.
Don’t use aggressive GC tuning without monitoring: Settings like -XX:MaxGCPauseMillis or -XX:G1HeapRegionSize can worsen performance if misconfigured. G1GC’s defaults are usually optimal.
Don’t ignore JVM warnings: Run Jenkins once and check the logs for JVM warnings about ergonomics or container detection. These often indicate configuration issues.
Don’t deploy to production without testing: Run under realistic load for at least 24 hours to observe GC behavior, memory growth, and response times.

Monitoring and Validation

Once deployed, monitor these metrics to validate your settings are working:

Garbage Collection

Use tools like jstat or observability platforms to track:

GC pause times (should be <1 second for G1GC in normal operation)
Full GC frequency (should be rare or non-existent)
Heap utilization patterns

Memory Usage

Monitor heap memory growth over time:

Watch for continuous growth (memory leak indicator)
Peak memory should stay below your MaxRAMPercentage setting
Initial memory should stabilize around your InitialRAMPercentage setting

Java Command Line

Verify settings are applied correctly:

Run jcmd <pid> VM.command_line to see actual JVM arguments
Check /proc/<pid>/environ (Linux) or ps output to confirm JAVA_OPTS are set

Simple Health Check

Enable basic logging:

JAVA_OPTS="
  -XX:+UseG1GC
  -XX:MaxRAMPercentage=60.0
  -XX:InitialRAMPercentage=20.0
  -XX:+PrintGCDetails
  -XX:+PrintGCDateStamps
  -Xloggc:/var/log/jenkins/gc.log
"

Monitor gc.log for unexpected pause times or full GC events.

Quick Rules of Thumb

Controllers: Prefer G1, aim for 50–65% of container RAM as heap.
Workers: Can tolerate 70–75% since workload is more predictable.
Don’t give the JVM the entire container: Leave at least 25–30% for OS and native memory.
Start conservative: You can always increase percentages if memory is being left on the table.
Monitor before tuning further: Most performance issues aren’t solved by tweaking JVM options.

Meet Jenkins at FOSDEM Brussels

2026-05-26T08:43:08+00:00

Meet Jenkins at FOSDEM Brussels

We’re excited to share that Jenkins has a stand at FOSDEM in Brussels this year!

If you’re attending, come by the Jenkins booth to say hello. Whether you want to talk CI/CD best practices, share what you’re building with Jenkins, ask questions, or just geek out about automation, we’d love to chat.

What is FOSDEM?

FOSDEM (Free and Open Source Developers' European Meeting) is one of the largest gatherings of open-source enthusiasts in Europe. It’s a free event that brings together developers, contributors, and users from around the world to share knowledge, collaborate on projects, and celebrate open-source software.

FOSDEM is all about community, and this is a great chance to meet Jenkins contributors and users face to face.

👉 Will you be at FOSDEM? Drop by the Jenkins stand and let’s talk — see you there!

Google Summer of Code 2026: Volunteers Needed to Mentor Future Jenkins Contributors

2026-05-26T08:43:08+00:00

TL,DR:

Jenkins is preparing to participate in its tenth (10th) year in Google Summer of Code (GSoC). We are seeking volunteers to be Jenkins mentors in the program:

Mentoring takes about 5 to 8 hours of work per week for a 10-22 weeks program.

Mentors provide guidance, coaching, review proposals, pull-requests, and contributor presentations.

Don’t have time to read? Watch this video.

What is Google Summer of Code?

Google Summer of Code (GSoC) is a global, online mentoring program focused on introducing new contributors to open-source software development. GSoC participants undertake a programming project lasting 10 to 22 weeks, guided by mentors from their chosen open-source organizations. This experience pairs accepted contributors with experienced developers, offering valuable exposure to real-world software development techniques. Contributors gain the opportunity to learn from seasoned open-source developers while writing code for real-world projects. A small stipend is also provided to support and incentivize their open-source contributions. Refer to the GSoC contributor eligibility documentation for more details.

Why might you consider being a Jenkins in GSoC mentor?

Participating as a mentor is crucial to the success of GSoC. Mentoring is a wonderful opportunity to give back to the community while improving your management and people (or general “soft”) skills. In return for mentoring, a GSoC contributor works on your project full-time for 10-22 weeks. Think about the projects you’ve always wanted to tackle but never had the time to complete. The Jenkins project is excited to participate in this fantastic program again in 2026, and we hope you will join us!

What does mentoring involve?

Potential mentors are invited to read the information for mentors. Serving as a GSoC mentor does not require expert knowledge of Jenkins. Mentors do not work alone, every project has at least two mentors. GSoC organization administrators will help find technical advisers, allowing you to learn together with your GSoC contributor.

Mentoring takes about 5 to 8 hours of work per week (more at the start, less at the end). Mentors provide guidance, coaching, and encouragement. They review GSoC contributor proposals, pull-requests, and presentations during the evaluation phase. Mentors also complete the Google-provided final evaluations at the end of the coding period.

So you want to be a mentor but don’t have a project idea? We can help with that!

GSoC project ideas are coding projects that potential contributors are expected to accomplish in about 10-22 weeks. The projects can include new features, plugins, test frameworks, infrastructure improvements, graphical interfaces, and more. If you don’t have a specific project idea, consider being a mentor for one of these project ideas. If you do have a project in mind, please submit it before the beginning of February so it can be reviewed by the GSoC committee and the Jenkins community. We would love for you to mentor your own project idea.

How to submit a project idea

Create a pull request with your idea in an .adoc file in the project ideas directory. Submitting a Google Doc is optional, though still acceptable. Refer to the instructions for submitting ideas, which include an .adoc template and examples.

Need more inspiration?

A great example is the Plugin Health Score. This GSoC project idea began in the summer of 2022 and was implemented in the summer of 2023, benefiting millions of Jenkins users worldwide!

We look forward to welcoming new mentors for GSoC 2026!

For any questions, you can find the GSoC Org Admins, mentors, and participants on the GSoC SIG Gitter chat.

2025 Jenkins Board and Officer Election Results

2026-05-26T08:43:08+00:00

The Jenkins community has completed the 2025 elections. On behalf of the Jenkins community and the elections committee, we congratulate all newly elected board members and officers! We also thank all candidates and voters who participated this year.

Election results:

Daniel Krämer joins Alexander Brandes, Valentin Delaye, Alex Earl and Basil Crow on the Jenkins Governance Board
Stefan Spieker will serve as Events Officer (uncontested)
Tim Jacomb will continue as Release Officer (uncontested)
Damien Duportal will continue as Infrastructure Officer (uncontested)
Wadeck Follonier will continue as Security Officer (uncontested)
Kris Stern will serve as Documentation Officer

The board positions and officer roles are an essential part of the Jenkins project and we are excited to see contributors taking these roles.

The board continues to require that no single company may have a majority on the Jenkins governance board.

Governance Board election details

This year we had three candidates for the Jenkins Governance Board, two for the Documentation Officer, and one for Events Officer. All of them are awesome community leaders who actively contribute to the Jenkins project and represent its users.

We used the Condorcet Internet Voting Service that allows voters to rank their choices rather than just picking their one favorite choice.

All board members are elected for a 2-year term. The estimated end of the term for them is December 15, 2027.

Officer election details

All 5 officer positions were up for election this year. These roles have a 1-year term, with the estimated end of term on December 15, 2026. After the initial review of nominations and confirmations with potential candidates, 3 officer positions were uncontested:

Stefan Spieker - Events Officer
Damien Duportal - Infrastructure Officer
Wadeck Follonier - Security Officer

Thanks to all Jenkins officers for their continued leadership! Officers take responsibility for many day-to-day processes in the Jenkins community and lead the contributor teams working on them. It requires significant time commitment and it is not taken for granted.

Statistics

This year we had 66 registered voters and 39 actual votes.

Feedback

The Jenkins project plans to conduct elections every year. We appreciate and welcome feedback regarding the election process so that we can improve the process.

If you have any private feedback you would like to share, please email the Jenkins Board. If you would like to raise any issues about the election process, please contact one of the elected Governance Board members.

Jenkins 2.543 and 2.541.1: New Linux Repository Signing Keys

2026-05-26T08:43:08+00:00

Beginning December 23, 2025 with 2.543, the Jenkins weekly releases will use new repository signing keys for the Linux installation packages. The same change will be made in Jenkins LTS releases beginning January 21, 2026. Administrators of Linux systems must install the new signing keys on their Linux servers before installing Jenkins Jenkins weekly 2.543 or Jenkins LTS 2.541.1.

Debian/Ubuntu

Update Debian compatible operating systems (Debian, Ubuntu, Linux Mint Debian Edition, etc.) with the command:

Debian/Ubuntu LTS release

curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2026.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

Debian/Ubuntu weekly release

curl -fsSL https://pkg.jenkins.io/debian/jenkins.io-2026.key | sudo tee \
  /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
  https://pkg.jenkins.io/debian binary/ | sudo tee \
  /etc/apt/sources.list.d/jenkins.list > /dev/null

Red Hat/CentOS

Update Red Hat compatible operating systems (Red Hat Enterprise Linux, Alma Linux, CentOS, Fedora, Oracle Linux, Rocky Linux, Scientific Linux, etc.) with the command:

Red Hat/CentOS LTS release

sudo rpm --import https://pkg.jenkins.io/rpm-stable/jenkins.io-2026.key

Red Hat/CentOS weekly release

sudo rpm --import https://pkg.jenkins.io/rpm/jenkins.io-2026.key

Frequently Asked Questions

What if I don’t update the repository signing key?

Updates may be blocked or interrupted by the operating system package manager (apt, yum, dnf) on operating systems that have not installed the new repository signing key. Sample messages from the operating system may look like:

Debian/Ubuntu

Reading package lists... Done
W: GPG error: https://pkg.jenkins.io/debian-stable binary/ Release:
    The following signatures couldn't be verified because the public key is not available:
        NO_PUBKEY 7198F4B714ABFC68
E: The repository 'https://pkg.jenkins.io/debian-stable binary/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Why is the repository signing key being updated?

The repository signing key expires after 3 years so that it matches with the expiration dates of the jar file signing and the MSI signing certificate. The updated GPG repository signing key is used in the weekly repositories and the stable repositories.

Which operating systems are affected?

Operating systems that use Debian package management (apt) and operating systems that use Red Hat package management (yum and dnf) need the new repository signing key.

Other operating systems like Windows, macOS, FreeBSD, OpenBSD, Solaris, and OpenIndiana are not affected.

Announcing the new Jenkins Bug Bounty Program

2026-05-26T08:43:08+00:00

It is with great pleasure that we announce the new Jenkins Bug Bounty Program! The European Commission (EC OSPO) has partnered with YesWeHack to launch bug bounty programs for several open source projects. The Jenkins project was selected as a valuable asset for public administration across the European Union.

The program will run for one year, rewarding security researchers who find and responsibly disclose security vulnerabilities in Jenkins.

Why a Bug Bounty Program?

Bug bounty programs complement our existing security practices by engaging the security research community in identifying and responsibly disclosing vulnerabilities.

This additional layer of scrutiny, combined with financial incentives, helps ensure Jenkins remains a secure and reliable automation server for organizations worldwide.

Program Details

Initial scope: Jenkins Core and its main components, and four plugins related to security

Reward: Up to €5,000 for valid critical findings!

Platform: Jenkins Bug Bounty Program on YesWeHack
Funding: European Commission

Depending on the level of interest and quality of reports, we will consider expanding the scope to other components of the Jenkins ecosystem.

For security researchers, it’s an additional reason to invest time on Jenkins. In addition to the white-box testing enabled by the open-source nature of the project, you can even get financial rewards for your efforts!

How Does It Work?

The in-scope reports are sent to the YesWeHack platform.
The initial triage is done by YesWeHack team.
Valid reports are then sent to the Jenkins Security Team for further analysis / validation, creating the corresponding SECURITY tickets.
Then the maintainers of the components are contacted to fix the issues.

This enhancement integrates seamlessly with our existing security workflow, while providing additional visibility and support from the European Commission and YesWeHack.

Thank You

We sincerely thank the European Commission and YesWeHack for making this program possible. Their support enables the Jenkins project to further strengthen its security posture and continue serving the open source community.

We invite security researchers to explore the program and help us make Jenkins more secure. Whether you’re a seasoned researcher or new to bug bounties, your contributions are valuable to the Jenkins community.

Happy hacking!

Automating Jenkins on Android with Infrastructure as Code

2026-05-26T08:43:08+00:00

From Manual to Automated

In March 2023, I explored running Jenkins on Android devices using Termux, demonstrating that it’s technically possible to transform aging smartphones into CI/CD infrastructure. The manual setup worked, but it required 2-3 hours of configuration and was error-prone.

Fast-forward to 2025: I’ve automated the entire process using Infrastructure as Code principles. What once took hours of manual configuration now completes in 15 minutes with a single command. This article presents the automation solution and the lessons learned while building it.

Why Automate Jenkins on Android?

The motivation is straightforward:

Reproducibility: Manual setups are difficult to replicate across multiple devices. Automation ensures consistency.
E-waste reduction: Millions of functional Android devices sit in drawers. Why not repurpose them as build agents?
Learning opportunity: Building this automation taught valuable lessons about service management, SSH configuration, and testing methodologies.
Cost-effective CI/CD: For small projects, hobbyists, or educational environments, repurposed phones offer free compute.

The goal wasn’t just to automate my setup—it was to create a reproducible solution anyone could use.

The Infrastructure as Code Solution

The complete automation is available at github.com/gounthar/termux-jenkins-automation. The solution uses:

Ansible: Infrastructure automation across 8 reusable roles
Jenkins Configuration as Code (JCasC): Declarative Jenkins configuration
Termux: Linux environment on Android without root access

Architecture Overview

The automation deploys a complete Jenkins infrastructure on a single Android device:

┌───────────────────────────────────────┐
│      Android Phone (Termux)        │
│  ┌──────────────────────────────────┐ │
│  │  Jenkins Controller (Minimal) │ │
│  │  - Port 8080 (Web UI)         │ │
│  │  - JCasC configured           │ │
│  └──────────┬───────────────────────┘ │
│            │ SSH (localhost:8022)  │
│  ┌──────────▼───────────────────────┐ │
│  │  Jenkins Agent (SSH)          │ │
│  │  - Build tools installed      │ │
│  │  - 2 executors                │ │
│  └──────────────────────────────────┘ │
└───────────────────────────────────────┘

The controller handles job orchestration while delegating builds to the agent (on the same device). This architecture mirrors production setups and teaches Jenkins best practices.

Eight Ansible Roles

The automation is organized into focused, reusable roles:

termux-base: Core Termux setup (SSH, Python, package management)
termux-complete-setup: Comprehensive package installation (59+ packages including build tools, languages, dev tools)
jenkins-controller: Jenkins installation and initialization
jenkins-agent: SSH agent configuration and workspace setup
jenkins-jcasc: Configuration as Code deployment
jenkins-backup: Job and configuration backup utilities
termux-boot-setup: Optional auto-start on device boot
termux-buildtools: Legacy build tools (superseded by termux-complete-setup)

Each role is idempotent and can be run independently or as part of the complete setup playbook.

Quick Start

The main orchestration playbook ties everything together:

# On the Android device (in Termux)
pkg install openssh python
sshd
passwd
whoami
ifconfig wlan0

# On your laptop/PC
git clone https://github.com/gounthar/termux-jenkins-automation.git
cd termux-jenkins-automation
./scripts/run-setup.sh

# Answer prompts:
# - IP address (from ifconfig)
# - SSH port (8022 default)
# - Username (from whoami)
# - Jenkins admin password
# - Authentication method (SSH key recommended)

# Wait ~15 minutes

# Access Jenkins:
# http://<phone-ip>:8080

The script handles prerequisites checking, inventory configuration, and playbook execution. No manual Ansible configuration required.

Key Technical Insights

Building this automation revealed several important lessons:

Service Management: runit over Background Processes

Initially, I ran Jenkins as a background process (java -jar jenkins.war &). This approach had problems:

Process dies when terminal closes
No automatic restart on failure
No log management
Difficult to monitor

The solution: Termux’s service management system using runit and sv:

# Jenkins runs as a managed service
sv status jenkins
# Output: run: jenkins: (pid 31647) 95s; run: log: (pid 26734) 4516s

# Service management commands
sv up jenkins      # Start
sv down jenkins    # Stop
sv restart jenkins # Restart

Logs are handled by svlogd with automatic rotation:

# View live logs
tail -f ~/.jenkins/logs/current

# All logs automatically rotated and compressed
ls -lh ~/.jenkins/logs/

This mirrors production service management and prevents the "my Jenkins died overnight" problem.

Fresh Installation Testing

The biggest mistake: testing only on my development phone. The automation worked perfectly… on the device I’d been configuring manually for weeks.

When I tested on a fresh Termux installation, it failed immediately. Missing dependencies that I’d installed manually months ago weren’t in the playbooks.

The fix: Systematic fresh installation testing on multiple devices. This revealed:

Missing repository configurations (needed root-repo and pointless repos for gcc-8)
Undocumented package dependencies
SSH key permission issues
Service startup race conditions

Fresh installation testing became part of the development workflow. Every change was validated on a wiped device.

Current success rate: 98% on fresh Termux installations (the 2% failure is usually network timeouts during package installation).

Jenkins Configuration as Code

Manual Jenkins configuration through the UI isn’t reproducible. The solution: JCasC (Jenkins Configuration as Code).

Complete Jenkins configuration in YAML:

jenkins:
  systemMessage: "Jenkins on Android (Termux) - Automated Setup"
  numExecutors: 0  # Controller doesn't run builds
  securityRealm:
    local:
      users:
        - id: "admin"
          password: "${JENKINS_ADMIN_PASSWORD:-admin}"

credentials:
  system:
    domainCredentials:
      - domain:
          name: "SSH Agent Credentials"
        credentials:
          - basicSSHUserPrivateKey:
              id: "termux-agent-key"
              privateKeySource:
                directEntry:
                  privateKey: "${readFile:/data/data/com.termux/files/home/.jenkins/ssh/id_ed25519}"

nodes:
  - permanent:
      name: "termux-agent-1"
      remoteFS: "/data/data/com.termux/files/home/jenkins-agent"
      launcher:
        ssh:
          host: "localhost"
          port: 8022
          credentialsId: "termux-agent-key"

The automation deploys this configuration, and Jenkins applies it on startup. No clicking through UI settings.

Lessons for Production Jenkins

While this project targets Android devices, the patterns apply to any Jenkins deployment:

Infrastructure as Code: All configuration in version control
Service Management: Proper process supervision (systemd, runit, etc.)
Configuration as Code: JCasC for reproducible Jenkins configuration
Fresh Installation Testing: Never assume dependencies are present
Modular Roles: Break automation into focused, reusable components

The termux-jenkins-automation repository demonstrates these principles in a constrained environment (no root, mobile platform, limited resources). If it works on Android, these patterns will definitely work on traditional servers.

What’s Next?

The automation is production-ready for single-device setups. Future enhancements could include:

Multi-device clustering: Coordinate multiple Android phones as a Jenkins cluster
Plugin automation: Automated plugin installation and updates
Backup/restore workflows: Scheduled backups to cloud storage
Performance optimization: Memory tuning for constrained devices
Monitoring integration: Prometheus metrics export

The foundation is solid. The patterns are proven. The infrastructure is code.

Try It Yourself

The complete automation, documentation, and troubleshooting guides are available at:

https://github.com/gounthar/termux-jenkins-automation

Requirements:

Android device with Termux installed
Laptop/PC with Ansible 2.10+
15 minutes

Whether you’re repurposing e-waste, building a home lab, or learning Jenkins administration, this automation provides a reproducible path from bare Android device to functioning Jenkins infrastructure.

From manual experiment to automated solution—that’s the Infrastructure as Code journey.

Related articles:

Advancing the Jenkins Tekton Client Plugin through CRD Generation, JUnit 5 Modernization, and Automated CI

2026-05-26T08:43:08+00:00

The Jenkins Tekton Client Plugin bridges Jenkins and Kubernetes-native Tekton pipelines, allowing Jenkins users to trigger and manage Tekton resources directly from their existing CI/CD workflows. Over the course of Google Summer of Code 2025, significant progress was made in modernizing, stabilizing, and extending the plugin’s capabilities.

This project introduced end-to-end CI automation, migrated tests to JUnit 5, implemented large-scale CRD-to-Java and UI generation systems, and improved Jenkins–Tekton interoperability.

Project Overview

The Jenkins Tekton Client Plugin enables Jenkins jobs to interact with Tekton resources such as Pipelines, PipelineRuns, and Tasks running on Kubernetes clusters. The goal of this GSoC project was to:

Modernize the build and testing infrastructure
Improve test coverage and reliability
Automate the generation of Java POJOs and Jenkins UI elements from Tekton Custom Resource Definitions (CRDs)
Strengthen the CI/CD integration between Jenkins and Tekton

All work was completed in close collaboration with the Jenkins community through public pull requests, reviews, and test deployments.

Continuous Integration and Build Automation

PR: #391 – Add GitHub Actions

A new GitHub Actions configuration was added to automate the build and testing process. Two workflows, test.yml and build.yml, now ensure that mvn clean verify and full build validation are executed on every commit. This CI layer ensures early detection of build issues and maintains consistent testing across environments.

PR: #393 – Update Jenkinsfile for Linux JDK 17

The Jenkinsfile was upgraded to use modern Linux agents and JDK 17, aligning the plugin with current Jenkins core requirements. This transition improves build consistency, performance, and future compatibility.

Documentation and Developer Experience

PR: #416 – Update README with comprehensive plugin documentation

The README file was rewritten to include installation guidance, usage examples, and CI/CD architecture explanations. A clear breakdown of supported Jenkins versions, Tekton compatibility, and build prerequisites was added, making the plugin more accessible for new contributors.

PR: #423 – Rename default branch to main

The default branch was renamed from master to main to follow modern repository standards. All workflow and build references were updated accordingly.

PR: #427 – Remove Windows support for CI

Windows testing environments were deprecated to streamline CI execution and reduce maintenance complexity.

Test Modernization and Migration to JUnit 5

PR: #421 – Migrate and Refactor Tests to JUnit 5

A full migration from JUnit 4 to JUnit 5 was completed. The modernized test suite enhances readability, reliability, and extensibility.

Highlights include: * Migration of CreateRawTest and CreateRawMockServerTest to JUnit 5 * Partial migration and modernization of JenkinsFreestyleTest and JenkinsPipelineTest * Reactivation of disabled tests * Adoption of parameterized and assertion-based testing features available in JUnit 5

This upgrade ensures the plugin aligns with the current Jenkins testing ecosystem.

Integration and End-to-End Testing

PR: #433 – Add Jenkins Build End-to-End Tests and JaCoCo Integration

Comprehensive end-to-end tests were introduced to validate interactions between Jenkins jobs and Tekton pipelines.

The following scenarios were implemented: * Freestyle builds with Jenkins environment variables * Parameterized pipeline builds with Tekton resources * Tekton pipeline execution from file-based definitions * Jenkins Pipeline integration using Tekton APIs

JaCoCo was also integrated to automatically measure test coverage. These tests ensure reliable behavior across Jenkins–Tekton workflows and serve as regression guards for future changes.

Bug Fixes and Functional Improvements

PR: #446 – Fix Duplicate @Symbol Annotation in tektonCreateRaw

Resolved a long-standing UI issue where the “Create Resource (Raw)” step was missing from the Jenkins interface due to duplicate @Symbol annotations. The fix restored visibility and configurability of Tekton resource creation within the Jenkins UI.

CRD to Java POJO Generation System

PR: #450 – Add CRD to Java POJO Generation at Maven Build Time

This was the core deliverable of the GSoC project. A new system was designed to automatically generate Java classes from Tekton CRDs at build time. This feature allows the plugin to stay in sync with evolving Tekton APIs without manual intervention.

Key components: * CrdJavaGenerator – integrates CRD generation into the Maven lifecycle * EnhancedCrdProcessor – parses CRD schemas and converts them into Java classes using jsonschema2pojo * Maven profile download-binaries – downloads Tekton CRD definitions during build * Generated POJOs include @DataBoundConstructor and extend Jenkins BaseStep for UI integration

The system now supports multiple Tekton API versions (v1, v1beta1, v1alpha1) and produces over one thousand Java classes that reflect the CRD specifications.

This automation significantly reduces maintenance burden and enables Jenkins to support new Tekton resources dynamically.

Unit Testing for the Generation System

PR: #480 – Unit Tests for CRD Generation System

An extensive test suite was implemented to validate the CRD-to-POJO generator. Tests cover: * Multi-version CRD compatibility * Field-level mapping and schema inheritance * Generated code compilation and JSON serialization * Integration between generated POJOs and existing Jenkins steps

Over fifty unit and integration tests ensure the generator behaves deterministically and maintains correctness across Tekton versions.

CRD to Jenkins UI Auto-Generation

PR: #484 – Add CRD to Jenkins UI Auto-Generation System

The second major feature developed during the project extends the generation pipeline to the Jenkins front-end. This system automatically converts Tekton CRDs into functional Jenkins configuration forms.

Core modules: * TektonCrdToJavaProcessor.java * AdvancedJellyConfigGenerator.java * JellyConfigGenerator.java * TektonPojoGenerator.java

The process transforms CRD definitions into structured Jenkins forms, automatically detecting data types and grouping configuration fields into logical sections such as metadata, spec, and parameters.

This lays the groundwork for dynamic UI generation in future Jenkins releases, allowing new Tekton APIs to appear automatically in the Jenkins interface without manual XML or Jelly coding.

Technical Takeaways

The project brought together multiple aspects of Jenkins plugin development, including CI automation, test modernization, and large-scale code generation. The most challenging aspect was maintaining compatibility between Jenkins’ job-based architecture and Tekton’s Kubernetes-native workflow model.

Key results: * JUnit 5 migration modernized the testing infrastructure. * Automated CRD and UI generation established a maintainable path for future Tekton API integration. * End-to-end testing improved confidence in Jenkins–Tekton interoperability.

GSoC 2025 Final Term: Build Retooling of jenkins.io

2026-05-26T08:43:08+00:00

This post marks the successful completion of my Google Summer of Code 2025 project: Complete Build Retooling of jenkins.io. Over the past months, we’ve transformed the Jenkins documentation infrastructure from legacy systems to a modern, performant, and well-organized platform.

Project Recap
Post-Midterm Achievements
1. Non-Versioned Site (Vite.js) Completion
2. Versioned Site (Antora) Enhancements
Technical Implementation Deep Dive
Challenges & Learnings
Future Roadmap
Acknowledgments
Project Resources

Project Recap

The initiative set out to achieve three core objectives for the Jenkins documentation system:

Modernization: Transitioning from legacy tools to contemporary solutions (Antora + Vite.js)
Performance: Implementing faster build processes and better user experience
Organization: Establishing clear separation between versioned content (LTS releases) and non-versioned content (general documentation)

By midterm, we had successfully laid the foundation with Antora for versioned documentation and Vite.js for non-versioned content, having migrated several core pages and established the basic architecture.

Post-Midterm Achievements

The second half of GSoC focused on completing the migration of all remaining components and polishing the user experience.

Non-Versioned Site (Vite.js) Completion

The Vite.js site saw comprehensive completion with the migration of all critical components:

Home Page: Fully implemented with dynamic content integration
Blog System: Complete migration with proper date handling and categorization
Security Advisories: Full security folder with all advisories and individual issue pages
Changelogs: Both LTS and weekly changelog pages implemented
UI/UX Polish:
- System-aware dark/light mode throughout
- Proper note icons and warning elements across all pages
- Consistent header and footer using jenkins-io-components
- Mobile-responsive design improvements

Key merged PRs include:

#43 - Home page implementation
#42 - Note icons correction across all pages
#40 - Changelogs integration
#39 - Security advisories folder
#37 - Blog system migration
#33 - Thank-you note on download page
#31 - Jenkins.io components header and footer

Versioned Site (Antora) Enhancements

The documentation repository received significant improvements:

UI Modernization: Updated styling and component consistency
Content Cleanup: Removal of redundant security folder (now in Vite.js site)
Navigation Improvements: Enhanced sidebar and navigation elements
SEO Foundation: Meta tags and search engine optimization setup

Key contributions:

#380 - Comprehensive UI changes and modernization
#379 - Removal of deprecated security folder
Ongoing cleanup and navigation link fixes

Technical Implementation Deep Dive

The migration employed several sophisticated technical approaches:

Content Transformation: Automated conversion of AsciiDoc to structured JSON/YAML for dynamic rendering in Vite.js
Component Architecture: Reusable React components for consistent UI across both platforms
Progressive Migration: Incremental page-by-page migration ensuring zero downtime
Visual Parity: Pixel-perfect matching with existing jenkins.io design language
Build Optimization: Streamlined build processes with proper asset handling

Challenges & Learnings

This journey presented numerous learning opportunities:

Content Scale: Managing thousands of documentation pages and blog posts required careful orchestration
Tooling Integration: Smooth coordination between Antora and Vite.js ecosystems
UI Consistency: Maintaining visual parity while modernizing the underlying technology
Community Collaboration: Learning to effectively communicate and coordinate with the Jenkins infrastructure team
Personal Resilience: Overcoming technical hurdles, hardware failures, and scheduling challenges

The experience strengthened not only my technical skills in modern web technologies and documentation systems but also my abilities in project management, communication, and open-source collaboration.

Future Roadmap

While the core migration is complete, several enhancements remain for future contributors:

Search Integration: Algolia search implementation for both sites
Performance Optimization: Image compression and build time improvements
Progressive Web App: Enhanced mobile experience and offline capabilities
Accessibility: Comprehensive accessibility audit and improvements
More UI Enhancements: Continue modernizing the Antora (versioned) site with consistent components and improved user navigation.
Community Contribution: Streamlined processes for community documentation contributions

Acknowledgments

This project’s success is a testament to the incredible support and guidance from my mentors: Kris Stern, Bruno Verachten, Kevin Martens, and Rajiv Singh. Their technical expertise, strategic guidance, and unwavering support were instrumental throughout this complex migration.

Special thanks to the entire Jenkins infrastructure team for their support and review, and to Alexander Brandes for guidance on search integration. The Jenkins GSoC org admins created a nurturing environment that made this learning journey possible.

For me, this has been more than a summer project; it’s been a transformative experience in open-source contribution, technical architecture, and professional growth.

Final Presentation

The final project presentation delivered a comprehensive overview of the completed work and technical achievements. You can view all GSoC 2025 presentations on the Jenkins in Google Summer of Code page.

Project Resources

The Complete Build Retooling project has initiated the retooling of the jenkins.io website as a modern, scalable, and maintainable documentation platform that will serve the Jenkins community for years to come. Thank you to everyone who supported this journey!

Revamped Tests UI in Jenkins

2026-05-26T08:43:08+00:00

The JUnit plugin has received a major redesign, focusing on a cleaner and more consistent UI. This work draws directly from the Pipeline Graph View plugin and the Jenkins Design Library, bringing much-needed polish to one of Jenkins' oldest plugins.

So what’s new?

New user interface

The plugin has been redesigned to make test results easier to understand at a glance. Pages have been streamlined, components simplified and standardized, and the overall experience given a major cleanup.

Test names are split more intuitively, based on method, class, and package. This makes scanning large test suites easier.

Stacktraces are now also syntax-highlighted for better readability, and they can now be copied with a single click.

Responsive

The interface now scales from the largest screen to the smallest, so you can check results even on the go.

Moments of joy

When all of your tests pass, enjoy celebratory confetti. Because we know the satisfaction of watching a suite go green after a stubborn failure.

Available now 🚀

The update is available now for users on Jenkins 2.504.3 and later.

See it in action in the Jenkins core build on ci.jenkins.io.

If you want to get involved in the UI and UX discussions of Jenkins join the User Experience SIG.

Take advantage of new components and patterns in your plugin via the Design Library.

You can watch our monthly meetings on YouTube and you can view in-progress work on GitHub.

Hacktoberfest 2025

2026-05-26T08:43:08+00:00

The annual Hacktoberfest is back! Please join us as we celebrate and support open-source during the month of October. Contributors can earn badges and improve their open source contribution skills.

The Jenkins project will participate once again in the event. We invite you to contribute to the Jenkins project but also, as maintainers, to welcome and help newcomers.

Contributors

This is what contributors need to know to participate and complete Hacktoberfest:

Register on the event website anytime between September 15 and October 31
Pull requests can be made in any jenkinsci or jenkins-infra GitHub repository that’s participating in Hacktoberfest (look for the "hacktoberfest" topic in the repo)
Project maintainers must accept your pull requests for them to count towards your total
Have a total of 6 high-quality pull requests accepted between October 1 and October 31 to complete Hacktoberfest
You will unlock a digital badge when you register for Hacktoberfest, and level it up with each of your 6 pull requests accepted during Hacktoberfest

Jenkins’ specific details can be found on the Jenkins Hacktoberfest page.

Some good resources for beginners can be found here:

Good first issues in Jenkins repositories:
- jenkinsci
- jenkins-infra
Intro to open source
- GitHub: How to contribute to Open Source
- DigitalOcean: Introduction to GitHub and Open Source Projects
- DigitalOcean: What is Open Source
- DigitalOcean: How to use Git: A Reference Guide
Sharpen your skills
The “improve a plugin tutorial” is an introduction to contributing to Jenkins.

Maintainers

Jenkins plugin maintainers can prepare for Hacktoberfest contributions by following these best practices:

Add the "hacktoberfest" topic to your repository to opt in to Hacktoberfest and indicate you’re looking for contributions. Only add the "hacktoberfest" topic to your repository if you are willing to promptly review Hacktoberfest pull requests

Add a CONTRIBUTING.md file with contribution guidelines to your repository

Apply the "good-first-issue" label to GitHub issues you want contributors to help with in your GitHub project
Add the “newbie-friendly” label to Jira issues that are well suited to new contributors
Choose issues that have a well-defined scope and are self-contained
Be ready to review pull requests, accepting those that are valid by merging them, leaving an overall approving review, or by adding the "hacktoberfest-accepted" label
Reject any spammy requests you receive by labeling them as "spam" and any other invalid contributions by closing them or labeling them as "invalid"

Introducing the Gradle Convention Plugin for Jenkins Plugin Development

2026-05-26T08:43:08+00:00

Building Jenkins plugins with Gradle just got easier!
Meet the modern, Kotlin-first, and convention-based Jenkins Gradle Convention Plugin. Plugin development made effortless 🏄‍♂️🏎️.
🌀 Try it today on the Gradle Plugin Portal

Today’s Jenkins Plugin Development Landscape

Apache Maven remains the primary and officially recommended build tool for Jenkins plugin development, powering the vast majority of plugins in the ecosystem. Its strong integration with the Jenkins plugin parent POM, extensive documentation, and mature lifecycle support make it the safest and default choice for most developers.

Gradle, while technically capable and widely adopted across the broader Java ecosystem, has seen limited adoption in the Jenkins community. It offers powerful advantages, including:

Extensible build logic defined in code rather than rigid XML.

Faster build times with incremental builds, caching, and the Gradle Daemon.

A developer-friendly experience with Kotlin and Groovy DSLs, plus interactive tooling.

Convention Plugins — a powerful way to share and reuse standardized build logic across projects. They can be combined like traits, much like multiple or diamond inheritance in OOP. In contrast, Maven’s parent POM model only allows a single parent (since Maven 3), forcing developers to rely on heavy profile usage and boilerplate.

Despite these strengths, Jenkins plugin development continues to be dominated by Maven. The primary reasons are that the core build infrastructure, tooling ecosystem, and CI pipelines are deeply aligned with Maven conventions.

The following table highlights some key differences between Maven and Gradle in the context of Jenkins plugin development.

Motivation

In late 2022, the Jenkins community identified significant gaps in Gradle support for plugin hosting and automation. At that time, new open source Jenkins plugins using Gradle were even blocked from hosting until those requirements were addressed.

This sparked discussions and community initiatives to close the gaps. The Jenkins Gradle Convention Plugin is a direct outcome of that effort, providing a standardized and supported way to build Jenkins plugins with Gradle.

Where the Gradle JPI Plugin falls short ?

The Gradle JPI Plugin provides a Maven-free path for Jenkins plugin development, but it falls short in matching the full Maven-based experience. Key limitations include:

Name	Previous Size (in KBs)	New Size (in KBs)
workflow-multibranch	4967	688
pipeline-groovy-lib	2267	564
workflow-scm-step	373	96