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.
