Hi everyone,
I’m Meet Goti, a Computer Science undergraduate. I’ve been contributing to Jenkins since December 2025 and have submitted 11 pull requests so far with 6 merged, including contributions to the resources-ai-chatbot-plugin, Jenkins Core and other plugins. I’m applying to GSoC 2026 for the AI Chatbot to Guide User Workflow project and wanted to introduce myself and share where my head is at with this.
Why this project matters to me
The thing that got me excited about this project is a pretty simple observation. When a Jenkins build fails, most users end up doing the same thing: open the console log, scroll through hundreds of lines, copy some error message, paste it into Google or ChatGPT, then come back and check the job config, then maybe look at the plugin docs. That whole loop can take 20-30 minutes for something that should take 2. The assistant already has access to all of that information. It just needs to be connected properly.
What makes an in-Jenkins assistant fundamentally different from just asking ChatGPT is context. An external tool doesn’t know which job you’re looking at, can’t read your build logs, and has no idea what plugins you have installed. You end up spending half your time just explaining your setup. A plugin that lives inside Jenkins can skip all of that.
What I’ve been working on
I’ve spent the last few months going deep into the Jenkins plugin ecosystem - Stapler, Jelly, the extension point model, how Launcher.LocalLauncher works for subprocess management, and the Credentials Plugin API. My contributions have helped me understand how Jenkins plugins actually work in practice, not just in theory.
I’ve also been studying the resources-ai-chatbot-plugin from GSoC 2025 closely. The sidecar architecture it established is solid and I think the right approach is to build on that foundation rather than reinvent it. My focus is on extending it with real context awareness, live Jenkins data access through MCP tools, proper RBAC integration, and a BYO-LLM model so admins aren’t locked into any single provider.
On the AI side, I have hands-on experience building RAG pipelines with LanceDB and LlamaIndex, working with tool-calling LLMs, and implementing multi-tenant isolation in vector databases. I’ve also been reading through the MCP 2025-11-25 specification to understand how the tool server should be designed.
My approach
Without going into full proposal detail, the core idea is:
- A Java-Python sidecar architecture where the plugin manages the Python process lifecycle through Jenkins’ own Launcher API
- A RAG pipeline for documentation retrieval so the assistant can ground its answers in real Jenkins docs
- An MCP tool server that gives the LLM controlled, read-only access to build logs, job configs, and build metadata
- DOM context extraction so the assistant knows what page you’re on without you having to tell it
- Security first: RBAC checks at every layer, log sanitization before anything reaches the LLM, credentials managed through the Credentials Plugin
I’ve scoped the project into clear tiers so the core deliverable is solid and achievable within the GSoC timeline, with stretch goals that add value but aren’t load-bearing.
Looking for guidance on
A few areas where I’d especially appreciate community perspective:
- For Jenkins admins who troubleshoot builds regularly - what questions do you find yourself asking most often? I want to make sure the tool design covers the real pain points, not just the obvious ones.
- Are there specific security concerns around an LLM having read access to build logs that I should be thinking about beyond credential leakage and prompt injection?
- For anyone who’s worked with the Stapler framework - any gotchas with SSE streaming through Stapler endpoints that I should plan around?
I’m also working on a proof-of-concept that demonstrates the core sidecar architecture and will share it as a draft PR soon.
Looking forward to contributing to Jenkins regardless of the GSoC outcome. Happy to discuss further.
@krisstern @shivaylamba would love to hear your thoughts on this.
Thanks,
Meet