My name is Rashi Verma. I am 2nd year Computer Science student from India ,currently focused on the landscape of ML and automation, and I am highly motivated to contribute to the AI Chatbot to Guide User Workflow project for GSoC 2026.
Coming from a Data Science background, I have extensive experience with Python and LLM orchestration (specifically RAG and context-aware prompting). However, I recognize that the soul of Jenkins is Java. I am not here just to build a standalone model; I am here to build a Jenkins tool.
I am currently:
Bridging the Gap: Actively learning the Jenkins Extension Point system and Stapler framework to ensure the AI integration is native and performant.
Studying the Core: Familiarizing myself with Jenkins Pipeline syntax to improve the chatbotās accuracy in guiding user workflows.
Ready to Work: I am looking for a āgood first issueāāideally one involving the UI or the Python-Jenkins APIāto prove my technical competence within the ecosystem before the proposal period begins.
I look forward to discussing how we can make Jenkins more intuitive through AI.
Regarding the language use of the user chatbot project, you can probably ombine both Java and Python in a Jenkins plugin by using Java for the plugin structure (extending Builder or Step) and using the Launcher API to execute Python scripts, or by employing tools like Py4j for direct inter-process communication. This allows leveraging Javaās Jenkins API access while utilizing Pythonās libraries. But we are open to alternatives too like using Shared Libraries to create a wrapper around some Python scripts, providing a higher-level, safe API for the plugin.
project, Iām currently leaning toward an approach that prioritizes stability and long-term maintainability. While Py4J enables powerful object-level IPC, a Launcher APIābased, process-oriented design feels more Jenkins-native and predictable, especially with respect to agent compatibility and operational safety.
Proposed approach:
Phase 1 (Launcher API PoC): Build a minimal, structured JavaāPython bridge using the Launcher API with explicit input/output contracts (e.g., JSON over stdin/stdout). This establishes a stable baseline that works across agents and environments.
Phase 2 (Py4J evaluation): Explore Py4J only if we identify concrete limitations where tighter, stateful interaction is clearly beneficial and justifiable.
Iām currently setting up JDK 21 and Maven using my-first-plugin and will share a technical update once the initial JavaāPython handshake via the Launcher is working.
Do you have any specific security constraints I should keep in mind while I build the Launcher PoC?
By Launcher API, I specifically mean using the hudson.Launcher class within the plugin to start Python as an external sub-process (on the controller or agent), with communication via well-defined input/output streams.
Regarding the alternatives you mentioned:
Jython: Iām inclined to avoid this path since it is limited to Python 2.7 and does not support the modern Python 3 ecosystem required for AI/LLM tooling.
Executing Python as a build step: This is a viable option, though Iām exploring whether a dedicated plugin-level bridge (using Launcher) would allow a more integrated āAI guideā experience while still keeping Python isolated from the JVM.
Work Update: Iāve verified my local plugin setup and extension points are functioning correctly. My next step is to prototype the Python bridge using the Launcher approach.
You can see my verified āHello Worldā output below.
Please let me know if this interpretation of the Launcher API aligns with your expectations, or if you would recommend a different direction at this stage.
Please accept my apologies for the delay in my response. I wanted to ensure I had a fully functional environment and concrete implementation results to share with you before getting back to you.
Over the past few days, I have successfully:
Modernized Jenkins Setup: Configured a Jenkins environment (LTS 2.479.1) with full Pipeline support. I successfully resolved several configuration hurdles to get the Pipeline Stage View and Pipeline REST API plugins working seamlessly.
Pipeline Implementation: Authored and executed a Jenkinsfile to understand the lifecycle of a build. Iāve attached a screenshot of my Stage View UI showing a successful multi-stage execution.
python-jenkins (v1.8.0) Integration: Iāve begun programmatically interacting with my local instance. I have successfully implemented and tested:
CRUD Operations: Creating, updating, copying, and deleting jobs via Python.
Build Automation: Triggering builds and fetching real-time status and build metadata.
Node and View Management: Fetching details about the Built-in Node and custom views.
This hands-on work has given me a clear understanding of how the python-jenkins library acts as a wrapper for the REST API.
As a next step, would you recommend diving deeper into advanced python-jenkins capabilities, or should I start drafting the high-level architecture for the proposal based on these findings?
Thank you again for suggesting python-jenkins ā it has been very helpful so far.
Iāve been diving deeper into LlamaIndex to build out the projectās backend. After successfully running a basic local RAG loop, I realized that simple vector search often loses the context needed for complex Jenkins logs.
To solve this, Iām currently exploring Recursive Retrieval using IndexNode. Iām learning how to link smaller text chunks to their parent nodes so the model can see the broader paragraph when it finds a specific error match.
For the integration, Iām sticking with python-jenkins via REST API for now. It feels more decoupled way to handle logs and metadata via API tokens while Iām still in the prototyping phase.
As I refine the proposal, should I focus on keeping this as a decoupled service, or is there a preference for it to eventually be more tightly integrated with the Jenkins core?
Hi @krisstern ,I have some updates from the past few days regarding my project**.** I have successfully implemented a platform-aware diagnostic agent. Below is the refined structure of my progress and current roadmap.
Technical Architecture:
My system utilizes a Decoupled Agentic RAG framework to ensure zero performance overhead on the Jenkins Controller.
Backend: FastAPI serving as the core orchestrator and session manager.
Data Layer: python-jenkins integration for real-time fetching of consoleText and build metadata.
Logic Engine: LlamaIndex with a RouterQueryEngine to intelligently switch between:
Troubleshooter: Direct log-to-solution diagnostic tool.
Navigator: Technical documentation search for setup queries.
Reasoning: Powered by llama-3.3-70b-versatile (Groq), utilizing a custom LLM Factory via Settings.llm for future-proofed model swapping.
Practical Implementations: āThe System DNAā
I have implemented a Heuristic Engine that automates context gathering without manual user input:
OS Syntax Anchoring: Automatically detects Agent OS (Windows vs. Linux) from log path patterns (e.g., detecting C:\ vs /var/).
Response Enforcements: Strictly enforces platform-specific syntax (e.g., bat for Windows builds, sh for Linux) to eliminate technical hallucinations.
Structured Output: Response schema designed to provide a Root Cause, Evidence (quoted logs), and a Technical Fix.
Challenges & Debugging Logs:
Cross-Platform Hallucinations:AI suggested Linux commands for Windows agents. Solved by anchoring the system prompt to the detected āDNAā OS tag.
Context Overload: Large logs exceeding token limits. Solved by implementing a HierarchicalNodeParser to chunk logs while maintaining parent context.
In the attached prototype demonstration, the agent correctly identifies a Windows-specific failure (Exit Code 9009) and suggests a valid bat-based remediation.
This demonstrates that the system has moved beyond generic log summarization into environment-aware executable diagnostics.
I am now moving into the Environmental Sensitivity phase:
Plugin-Awareness (Active): Integrating logic to check the controllerās installed plugins via API. The AI will only suggest tools that the system actually possesses.
Multi-Job Context Analysis: Implementing a āSuccess-Failure Diff.ā The agent will compare the last successful build with the current failure to pinpoint exactly which change caused the break.
Multi-Job Context Strategy:
For the upcoming āSuccess-Failure Diffā implementation, Iām evaluating two prioritization paths:
Git commit diffs
Jenkinsfile configuration diffs
My current inclination is to prioritize Jenkinsfile configuration diffs first, as CI failures often stem directly from pipeline definition changes. However, Git diffs could provide broader regression context..
I would really value your thoughts on whether this direction aligns with the long-term vision for Jenkins AI tooling, and any guidance on the next steps.
I am planning the architecture for the AI Chatbot and I have a question regarding the environment.
To use LlamaIndex and Pythonās ML libraries effectively, I am proposing a FastAPI microservice that communicates with the Jenkins Java plugin via a REST API.
My question is: Does the Jenkins community prefer this Python service to be something the user installs locally alongside their Jenkins controller, or should the plugin connect to a remote, centralized API hosted by the project?
I want to ensure my proposal handles the āDependencyā problem (requiring the user to have Python) in a way that aligns with Jenkinsā standards.
As a contributor to the resources-ai-chatbot-plugin, I wanted to confirm that this āAI Chatbot to guide user workflowā project is one of the āfuture enhancementsā we discussed in the recent community post.
the features mentioned here (like guiding users through complex pipelines) are high priority said by @berviantoleo . Itās great to see you bridging the gap between Python (for the AI/LLM part) and Java (for the Jenkins core).
if you need any clarification on the current plugin architecture or specific Jenkins Extension Points to make this work, feel free to askā¦
Thank you for the clarification! Yes, I am focusing specifically on the āAI Chatbot to Guide User Workflowā project.
While my project is separate from the resource-ai-chatbot-plugin, I would learn more about the Jenkins Extension Points as you mentioned. Specifically, I am looking into how to best anchor a chat UI within the Jenkins Dashboard and which extension points would allow the bot to read pipeline logs for real-time troubleshooting.
@berviantoleo I aware that, those two are seperate initiatives. I just wanted to check if thereās any overlap in the future features (like agentic debugging or deep context) we might be able to share or align on ,so we donāt end up duplicating work, like thatā¦
@RashiV If you are diving into those Extension Points for the Workflow bot, feel free to ping me,I would be happy to share what we have learned in the resources-ai-chatbot-plugin repo to help youā¦
My name is Padmini, an MTech CSE student from Hyderabad, India. I have prior industry experience at Accenture as a Software Engineer Associate, where I worked on Spring Boot microservices, Jenkins CI/CD pipelines, and JUnit testing.
Iām already an active GSoC 2026 contributor ā Iāve forked the email-ext plugin and am contributing to the Jenkins Email Notifications via Outlook OAuth project. This means Iām already comfortable with Jenkins plugin architecture, the Maven build system, and @Extension points.
Iād like to apply for the AI Chatbot to Guide User Workflow project. Having read the thread carefully, I see the core challenge is building a robust Java plugin layer that anchors the chat UI natively in the Jenkins Dashboard and exposes the right Extension Points ā while delegating AI reasoning to a Python FastAPI service.
My focus will be on the Java side of this bridge, specifically:
Implementing a native Jenkins panel using hudson.model.Action to embed the chat UI
Designing the REST endpoint within the plugin that the FastAPI service calls back into
Ensuring the plugin reads consoleText and build metadata using Jenkinsā internal APIs (not just python-jenkins externally)
I have a question for the mentors: Is the preferred UI approach a Jelly-based side panel attached to each build page, or a global Jenkins Dashboard widget accessible from anywhere? This will shape the Extension Point selection significantly.
