[GSoC 2026 PROPOSAL] Adarsh Gaonkar - Agentic CI/CD Debugger for Resources AI Chatbot

Hi Jenkins Community and Mentors!

My name is Adarsh Gaonkar. I am an engineering graduate with a strong interest in DevOps and infrastructure engineering.

I have recently been contributing to the resources-ai-chatbot-plugin (PRs #186 and #187 covering data ingestion pipeline fixes and Pytest 8.0 test architecture consolidation).

I am very interested in the “Continue AI-Powered Chatbot” project for GSoC 2026. The project description mentions adding an “agentic mode,” so I have drafted a proposal to build an Agentic CI/CD Debugger. The goal is to upgrade the chatbot from a read-only documentation searcher into an active debugging assistant that can securely fetch a user’s failed build logs via the Jenkins REST API, chunk the massive console output to isolate the stack trace, and inject it into the LLM context to suggest Jenkinsfile fixes.

I have outlined a 12-week timeline and system architecture in this Google Doc:[GSoC 2026 PROPOSAL] Adarsh Gaonkar - Agentic CI/CD Debugger for Resources AI Chatbot - Google Docs

I would be incredibly grateful for any feedback from the mentors, specifically @krisstern and @berviantoleo, so I can refine the architecture and ensure the log-chunking approach aligns with your vision before the official application period opens.

Thank you for your time!

Hi

Some of the points make sense to have in explain error plugin like chunking large context with filtering. I have started to implement something like that but not have time to complete. Then I suggest to start from there to extend it with some endpoint etc. Is that ok? Better to have more consistent set of plugins

Welcome to the community.

I suggest measuring the task with reasonable timeline. As some big chunk work, it may be not sufficient to finish it in one week. Measure the review time and testing time. I will encourage there is a testing before we move to another feature/bug fixing.

Hi Michael! That is incredibly helpful to know. Integrating with the existing ‘Explain Error Plugin’ makes perfect sense and aligns much better with Jenkins’ modular ecosystem. I will take a look at the codebase you started and update my proposal’s architecture section to reflect building on top of that foundation. Thank you for pointing me in the right direction!

1 Like

Hi Leo, thank you for the welcome and for taking the time to review my draft! That is a very realistic and practical point. I will revise the Google Doc timeline today to explicitly include dedicated blocks for Unit/E2E testing and mentor review cycles before moving between phases. I appreciate the guidance!

1 Like

hey Adarsh, solid plan! I completely agree that turning the bot into a CI/CD debugger is the logical next step for an agent mode.

@berviantoleo makes a great point about testing time. Since your agent will be actively hitting the Jenkins REST API to fetch large logs, what’s your strategy for writing the automated tests? will you be mocking the Jenkins instance and the API responses entirely, or are you planning to spin up a test Jenkins environment during the CI pipeline to run integration tests against real build failures?