sharma-sugurthi

Posted on Mar 10

So You Want to Contribute to Jenkins? Here's Everything Nobody Told Me

#opensource #jenkins #beginners #devops

Let me be real with you.

When I first decided to contribute to Jenkins, I opened the GitHub page, stared at it for ten minutes, and then went and watched YouTube instead.

It felt big. Like showing up to a party where everyone else knows each other and you're holding your jacket wondering if you should even stay.

If that's you right now, good. You're in the right place. This blog is everything I figured out the hard way, written in simple English, so you don't have to.

First, What Even Is Jenkins?

Jenkins is an open-source automation server. It helps software teams build, test, and deploy their code automatically. Think of it as the robot that runs your tests every time you push code to GitHub, so your teammates don't have to.

It's been around since 2011, it has over 1,900 plugins, and it runs in production at companies you definitely know. It's also one of the most active open-source communities on the planet.

So yes, contributing here actually means something.

Where Does the Code Live?

Jenkins isn't just one repository. It's spread across a few GitHub organizations:

Organization	What it contains
jenkinsci	The main Jenkins core + almost all plugins
jenkins-infra	The infrastructure running jenkins.io and ci.jenkins.io
jenkins-ci	Older/legacy tooling

For most contributors including me, especially beginners - jenkinsci is where you start.

How Do I Find a Project to Contribute To?

A few good places:

Good First Issues - search across the entire jenkinsci org for issues labeled good first issue. These are literally tagged by maintainers for people like you and me.
GSoC Project Ideas - if you're applying for Google Summer of Code, this is the list of officially mentored projects. Each has a description, a mentor, and links to the codebase.
Jenkins Plugins Index - if you already use a Jenkins plugin and notice something broken or missing, that plugin probably has a GitHub repo under jenkinsci. Just search jenkinsci/<plugin-name>.
Success Stories - read what people built with Jenkins to understand what problems the community is solving. Inspiration hits differently when you see real use cases.
Previous GSoC Projects - past contributors and what they built. One of those projects might need a follow-up contributor. That's how many people get their first foothold.

Okay, I Found a Project. Now What?

Step 1: Read Before You Touch Anything

Seriously. Read the README.md. Read CONTRIBUTING.md if it exists. Read the open issues. Read the closed PRs from the last month.

I know you want to code. But 80% of bad first contributions happen because someone didn't read what already exists. Don't be that person.

Step 2: Set Up the Dev Environment

Every project has setup instructions. Follow them exactly. If they don't work, that is your first contribution - fix the docs so the next person doesn't suffer.
In my case while I setting up the Environment, I find it quite time taking to set up the Environment so raised an issue and also successfully merged my PR.

For the Jenkins AI Chatbot Plugin (project I contributed to), setup involves Docker, a Python virtual environment, and an LLM model download. The README.md walks through it. If something breaks, check the open issues, it's very likely someone else hit the same thing.

Step 3: Understand the Codebase (Briefly)

You don't need to understand everything. You just need to understand enough to fix the thing you're fixing.

Clone the repo
Run the app
Click around / send API requests
Open the relevant file and read it

A 30-minute exploration beats a 3-hour read of every file.

Raising an Issue

Found a bug? Want to suggest something? Great. But before you raise an issue:

Search first. GitHub's search is right there. Type a keyword. If your issue already exists and you raise a duplicate, the maintainer will close it and you'll feel weird.
Be specific. "It doesn't work" is not a bug report. "When I send message X, I get error Y on line Z" is a bug report.
Include steps to reproduce. If a maintainer can't reproduce your bug, they can't fix it.
Don't claim ownership aggressively. Don't comment "I'll fix this" on ten issues and then disappear.

Good issue template to follow (I personally follow this):

What happened:

Expected behavior:

Steps to reproduce:

Environment: (OS, Python version, etc.)

Submitting Your First PR

This is the moment. The commit message anxiety.

Here's the practical flow:

Fork the repo (your own copy on GitHub)
Create a branch with a descriptive name: fix/session-delete-disk-cleanup not my-fix or branch1
Make the change, write a test if needed
Run CI locally - check if there's a pylint or pytest command in the docs. Run it before you push. CI failing on your PR is embarrassing (again, speaking from experience)
Open the PR against the main branch of the original repo
Write a good description - what problem did you solve, how, and how can the reviewer verify it? Link the issue it closes with Closes #<issue-number>

Sample PR description:

Summary
Fixes the session delete endpoint not cleaning up disk-persisted files.

Problem
delete_session() removed the in-memory session but left .json files in /data/sessions/, causing storage buildup over time.

Fix
Added os.remove() call after in-memory cleanup. Wrapped in try/except to handle already-deleted files gracefully.

Testing

Ran pytest tests/test_session.py - all pass

Manually verified file deletion via ls data/sessions/ before and after

The Code of Conduct (Please Don't Skip This)

Jenkins has a Code of Conduct and it's taken seriously. The short version:

Be respectful. Everyone here is volunteering their time.
Keep technical criticism constructive. "This code is bad" helps no one. "This could be simplified by doing X" helps everyone.
No harassment, no personal attacks, no publishing private info.

Violations can result in warnings, temporary bans, or permanent removal. The board handles this privately and quickly.

Where to Talk to People

Jenkins Discourse - for longer discussions, GSoC questions, project proposals. Think of it like a forum.
Jenkins Gitter - for quick questions. The GSoC channel is active during application season.
GitHub Issues / PR comments - for project-specific technical discussion

Pro tip: When you join Gitter, actually say hi and ask a relevant question. Lurking for weeks and then suddenly saying "please review my PR" is not a great introduction.

Spotlight: The AI Chatbot Plugin (This is the project I worked on)

If you're looking for a project to start with, I'm biased - but for good reason.

resources-ai-chatbot-plugin is mostly Python + React - the AI brain, the API, the retrieval system, all Python. There's one 8-line Java file that registers it as a Jenkins plugin, but you'll never need to touch it as a contributor. Just:

A FastAPI backend
A RAG (Retrieval-Augmented Generation) AI pipeline
A React frontend with WebSocket streaming
FAISS vector store + BM25 keyword search

It's a GSoC 2025 project being continued in 2026, so the codebase is active, the issues are real, and the mentors are responsive.

Open issues right now include UI improvements, session management fixes, test coverage, and AI pipeline enhancements. The good-first-issue label points you to the easiest entry points.

You're Not Too Late, You're Just Starting

The Jenkins community has been running for 15+ years. Hundreds of contributors have passed through, added something, and moved on. Some became maintainers. Some got GSoC seats. Some just fixed one bug and left.

All of it counts.

Your first issue doesn't have to be brilliant. Your first PR doesn't have to be perfect. It just has to be genuine.

Start small. Read carefully. Ask questions. Be patient with review cycles.

See you in the PRs.

Useful Links

- Manisharma Sugurthi [ GitHub | LinkedIn ]

DEV Community