Jenkins Blog

Revamped Build Monitor plugin

2026-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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 [email protected]">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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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-03-19T18:14:09+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:

Jenkins Blog

Revamped Build Monitor plugin

Introducing the Jenkins Plugin of the Month

Jenkins Contributor Summit: Officers View on the Present and Future

Jenkins Contributor Awards 2026 - Nominations are Open

Impressions from Jenkins Contributor Summit in Brussels

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

Impressions from Jenkins Stand at FOSDEM Brussels

Tuning Jenkins Java Settings For Responsiveness and Stability with Large Instances

Meet Jenkins at FOSDEM Brussels

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

2025 Jenkins Board and Officer Election Results

Jenkins 2.543 and 2.541.1: New Linux Repository Signing Keys

Announcing the new Jenkins Bug Bounty Program

Automating Jenkins on Android with Infrastructure as Code

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

GSoC 2025 Final Term: Build Retooling of jenkins.io

Revamped Tests UI in Jenkins

Hacktoberfest 2025

Introducing the Gradle Convention Plugin for Jenkins Plugin Development

GSoC 2025 Endterm - Improving Plugin Modernizer