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 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.
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
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!
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!
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?
Hey @sharma-sugurthi, thanks! That is exactly what I was just thinking about. To keep the CI pipeline fast and avoid flaky network errors, my strategy is to lean heavily on mocking the Jenkins REST API for the core unit tests. I’ll be creating sample JSON payload fixtures of actual Jenkins build failures and using Python’s unittest.mock to simulate the fetching process. This way we can thoroughly test the agent’s logic and token-limit handling without adding minutes to our CI run time.
I wanted to provide an update on my application! Since my initial draft last month, I have spent significant time deep-diving into the chatbot-core backend, where I recently got PR #195 (resolving tool registry crashes) and PR #268 (sanitising AWS keys before LLM injection) merged.
Based on my hands-on learnings from the architecture, I have completely rewritten my proposal into a formal 12-week technical execution plan following the official Jenkins template.
Link to Final Proposal: (Link removed for privacy)
I have left commenting turned on in the document. If you have the bandwidth before the March 31st deadline, I would be incredibly grateful for any final feedback on the timeline or architectural approach.