What stays in Jenkins	What moves to the platform
SCM triggers, build agents, shared libraries	Environments and promotion
Test orchestration, the plugin ecosystem	Per-environment config and secrets
Build credentials, pre-build approvals	Multi-cluster placement
Build provenance and logs	Runtime observability, self-service catalog

Value	Default on a quick-start install
Thunder token endpoint	`http://thunder.openchoreo.localhost:8080/oauth2/token`
OpenChoreo API	`http://api.openchoreo.localhost:8080`
Client ID	`openchoreo-workload-publisher-client`
Client secret	`openchoreo-workload-publisher-secret`

Time (CEST)	Session	Activity
08:30	Tech Prep	Moderator opens the Zoom/Teams bridge and pins the GitHub Repo link.
09:00	Opening Plenary	Livestream: Welcome, 2026 Roadmap, and “How to use the Repo” tutorial.
09:30	Squad Formation	Breakout rooms of 4 people. Each squad picks a GitHub Issue to “own.”
09:45	Interactive Intro	Squad Task: 15 mins of personal intros + creating their Google Doc (linked in their GitHub Issue).
10:15	Working Session A	Hackathon: Live coding/doc writing. Moderator “visits” rooms to unblock squads.
12:00	Showcase 1	Squads post their progress/PR links in the GitHub Issue. Quick 2-min demos.
12:30	Mid-Day Sync	Moderator Note: Label issues as [Status: In Progress] or [Status: Needs Handover].

Time (CEST)	Session	Activity
15:00	Re-Opening	Moderator summarizes morning wins. Introduce the “Handover” issues for newcomers.
15:30	Squad Formation	New squads of 4 people. Mix of fresh Americas faces and lingering EMEA contributors.
15:45	Interactive Intro	Squad Task: Intros + “Adopting” an Issue. If it’s a handover, they read the previous squad’s Google Doc.
16:15	Working Session B	Hackathon: Deep work. Americas morning energy meets EMEA afternoon focus.
18:00	Final Sprint	“Last call” for Pull Requests. Moderator helps with training and reviews.
19:00	Global Showcase	Final demos of the day’s achievements. Credits and closing remarks.
19:30	Hard Stop	Moderator closes the bridge.

Jenkins Blog

GSoC 2026 Final Blog: How It Was to Be a Contributor at Jenkins

2026-09-13T16:43:23+00:00

Hello everyone!

I am Mallikarjun G D, and I have been a GSoC 2026 contributor for the project Continue: AI-Powered Chatbot for Quick Access to Jenkins Resources. Over the past few months, I have learnt a lot, not just about AI and Jenkins, but also about contributing to a large open-source project. So for my final GSoC blog, I wanted to share how the whole journey actually went.

Before GSoC

My journey with Jenkins started pretty randomly. I was learning Jenkins, got curious about its open-source codebase, and while exploring the GitHub organization, I stumbled across the resources-ai-chatbot-plugin.

I found out it had started as a GSoC 2025 project, cloned it, tried running it, and eventually filtered the Issues page by good-first-issue.

And of course, I found a README issue the classic open-source starter pack.

I worked on a small setup guide, fixed a few missing links, and opened my first pull request.

And there it was my first open-source PR.

After that, I slowly moved from documentation issues toward code-related contributions. By the time GSoC applications opened, I had around five or six PRs and a much better understanding of the project.

I started my proposal early, focused on areas that matched both the project priorities and what I wanted to learn, went through the interview, and then came the selection.

That was when the real journey started.

During GSoC at Jenkins

The first few weeks were a mix of excitement and nervousness. Community bonding helped me understand the workflow, get comfortable with my mentors, and settle into regular coding, PR reviews, bi-weekly meetings, and weekly GSoC stand-ups.

One early lesson came while working on LLM-as-a-Judge. I was stuck improving the faithfulness score and kept tuning the same things. A mentor suggested changing the evaluation template itself, and that worked almost immediately. It taught me to step back and rethink the approach instead of endlessly tuning the same solution.

The hardest part was burnout when my college exams overlapped with the coding period. Until midterm, I had also put a lot of pressure on myself simply because it was GSoC. After midterm, that changed, and the work started feeling much more like normal open-source contribution and learning.

The project was also extended by two weeks, giving me some additional time to complete the remaining work.

GraphRAG gave me another memorable challenge. My first documentation-based graph was too small, so I researched further and found Jenkins Update Center data. Rebuilding around it gave me roughly 5,000 relationships, which was one of the most satisfying moments of the project.

Over time, I also started thinking more about testing, edge cases, maintainability, smaller PRs, and reusing existing architecture. Most importantly, I became much more comfortable asking questions and discussing ideas with maintainers.

By the end, GSoC felt less like something I had to prove myself through and more like something I genuinely enjoyed being part of.

The Features I worked on:

LLM-as-a-Judge Evaluation

The first major feature I worked on was an LLM-as-a-Judge evaluation pipeline.

The goal was to move away from manually judging whether chatbot changes were actually improving responses. I built an evaluation flow using a fixed golden dataset and DeepEval, measuring Faithfulness, Answer Relevancy, and Contextual Recall directly in CI.

This feature taught me a lot about evaluation beyond just looking at model outputs. I also had to deal with model runtime, quantization, CI limitations, caching, and making the evaluation stable enough to be useful during development.

GraphRAG for Relationship Queries

The next feature was GraphRAG, mainly for Jenkins plugin dependency queries.

Semantic retrieval works well for documentation questions, but it struggles when relationship direction matters. For example, "What does git depend on?" and "What depends on git?" look very similar to a vector retriever but need completely different answers.

I built a directional plugin graph using Jenkins documentation and Update Center data. The graph now contains roughly 5,000 relationships across around 1,400 plugins, while normal documentation queries still continue through semantic retrieval.

This was probably the feature that taught me the most about how retrieval systems work underneath, and when structured retrieval is more useful than semantic similarity.

Build Failure Diagnosis Agent

The third feature was the Build Failure Diagnosis Agent.

Jenkins console logs can become extremely long, even when only a few lines actually explain the failure. The agent extracts the relevant error section and sends that focused context to the chatbot.

While building this, security became an important part of the design. Build logs can contain API keys, tokens, and other sensitive values, so the extracted snippet is sanitized before it reaches an external LLM.

This feature made me think much more carefully about what data should reach an LLM in the first place, rather than simply sending everything and expecting the model to handle it.

Third-Party LLM Provider Support

One additional feature I worked on was third-party LLM provider integration.

Previously, the chatbot mainly depended on running a model locally. That made development difficult for contributors without a capable GPU, which was something I faced myself.

I added provider routing through LiteLLM, along with a frontend provider and model selector. The chatbot can now work with providers such as Groq, OpenRouter, Gemini, Claude, and OpenAI, while still supporting local inference.

Providers are configured through providers.json, and credentials use a per-user Bring Your Own Key setup.

Interestingly, this ended up being the feature I enjoyed working on the most. By this point I was much more comfortable with the codebase, and it felt less like figuring out how the project worked and more like actually building within it.

Jenkins Plugin Installation Experience

Another feature I worked on was improving the Jenkins plugin installation experience. Previously, installing the plugin did not automatically give users a complete chatbot interface because the frontend still had to be run separately.

The React frontend is now bundled directly inside the Jenkins plugin HPI, so installing the plugin through Jenkins makes the chatbot UI available without requiring a separate frontend server. The plugin connects to the FastAPI backend through a Jenkins-configured backend URL, with Jenkins acting as the same-origin API gateway between the frontend and backend.

The backend remains separately managed and can be started in a local setup. This keeps Python dependencies and backend services outside the Jenkins process while making the plugin itself much easier to install and use.

What Comes Next

Even though GSoC is ending, there are still a few things I would like to continue improving in the project.

Some of the next areas are:

Expand GraphRAG to cover more conflict and incompatibility relationships.
Integrate Jenkins authentication and authorization so user context stays private, anonymous users only access public information, and data is not exposed across users.

More importantly, I would like to continue contributing to Jenkins instead of treating the final evaluation as the end of the project.

Looking Back

The biggest change for me was probably how comfortable open source feels now.

Before GSoC, even opening a pull request felt like a big deal. Now, reading a large codebase, discussing ideas with maintainers, asking questions, getting reviews, and iterating on changes feels much more natural.

I also stopped looking at GSoC as something I had to constantly prove myself through. Somewhere along the way, it simply became a project I genuinely enjoyed working on and learning from.

That transition is probably what I will remember the most.

Acknowledgements

A huge thank you to my mentors, V. Sreenivas, Bervianto Leo Pratama, and Giovanni Vaccarino and special mention to Kris Stern for their guidance, reviews, and patience throughout the project.

A lot of my learning came from discussions where they did not just tell me what to change, but helped me understand why a different approach would be better.

I would also like to thank the Jenkins community, the GSoC organization team, and the other contributors I interacted with throughout the program. Being part of the community made the whole experience much more enjoyable.

Final Note

If there is one thing I would tell someone who is thinking about contributing to open source, it is to just start.

My journey began with a small README issue because I had no idea where else to begin. That one contribution slowly turned into more issues, more code, a GSoC proposal, and eventually several months of working with the Jenkins community.

You do not need to know everything before contributing. Ask questions, start small, and keep going.

Follow Along

Repository: jenkinsci/resources-ai-chatbot-plugin
GitHub: arjun-713
LinkedIn: Mallikarjun G D

Investigating Build Regressions From the Last Known-Good Build

2026-09-13T16:43:23+00:00

The following scenario is a case study. A Jenkins build fails in an integration test. The console contains a NoSuchMethodError, so the immediate task seems straightforward: find the incompatible dependency. Then someone points out that the last three builds failed too. Another developer asks whether the dependency change was already present in a successful build. The error is useful, but it has not yet established the investigation boundary.

That boundary matters. A log describes what happened during one execution. Investigating a regression also requires knowing what worked before it, which changes arrived afterward, and whether later failures represent the same problem.

The question is: what changed between the last successful build and the failed build, and which changes are most likely related to the regression?

Starting there gives the investigation an order. Establish the successful baseline. Examine the changes after it. Locate the first matching failure when the retained history supports that conclusion. Then connect those changes to the diagnostic and decide what to inspect first.

Establish the window before reading every change

Consider this synthetic payments build history. It is an illustrative investigation, not a report of a production incident:

The failure occurs during payments integration tests. The retained diagnostic includes NoSuchMethodError and the relevant stack frame. SCM history contains changes to payment-common/pom.xml, PaymentClient.java, documentation, and an unrelated service.

If we compare only #872 with #873, we may concentrate on a change made after the problem began. If we collect everything between #869 and #873 and give every file equal attention, later changes can obscure the earlier candidates.

The complete retained sequence supports a more useful window: #869 to #870. Build #870 is the first bad build in this observed sequence, while #873 supplies the current failure signal. Those are different roles and should remain visible.

A real V3 runtime capture using synthetic data: the change window stays beside the failure evidence.

Build numbers alone are insufficient. If #872 has been deleted, or it was aborted, the sequence no longer verifies a continuous run of matching failures. An investigation should then say that the first bad build could not be narrowed. It should not silently bridge the gap because #871 and #873 look alike.

Even a verified boundary does not prove that a commit caused the failure. A changed runtime dependency, external service, or environment could still be involved. What the boundary establishes is where the retained build evidence places the start of this failure sequence.

Connect a diagnostic to a candidate, then state the limitation

In the payments example, NoSuchMethodError makes dependency compatibility worth inspecting. It does not, on its own, tell us which dependency declaration is responsible. The exception, missing method, stack frame, build-task context, and changed paths need to be considered together.

Suppose the retained task output explicitly names payment-common, and its pom.xml changed in the narrowed window. That is a useful deterministic relationship: a file changed within the module named by the failing task. The next check is the module diff and the runtime classpath. The relationship does not establish which artifact was actually loaded when the test ran.

A changed PaymentClient.java may offer a different relationship if the diagnostic names that source file. It deserves early inspection, but “the file changed” still does not mean “the failing line changed.” The diff must answer that second question.

Stage context needs similar care. A stage label matching the first component of a changed path can help order the candidates. A changed Jenkinsfile may also be relevant when a failing stage is observed. These are indirect clues. They do not establish that a particular configuration change executed in that stage or that the stage used a particular checkout.

Ranking provides an inspection order while keeping the other retained changes available.

The unrelated documentation should remain accessible. It should not receive the same prominence as a source path named by the failure, and it should not be declared harmless simply because no direct relationship was found.

This is also why the explanation beside a ranking matters more than its position. “Strong evidence” is useful when it refers to a stated relationship. An unexplained confidence percentage would give the engineer less to verify.

Put the exact failure where the engineer starts

Console Output remains necessary for many investigations. It should not be necessary merely to discover the diagnostic that the investigation is discussing.

For a compiler failure, the useful starting point may be a file, line and column, followed by cannot find symbol and the unresolved symbol. For the payments failure, it is the API linkage error and the relevant stack frame. A test failure may need the test name. The form varies; the requirement is to preserve the evidence that makes the next check specific.

A short description such as “dependency issue” throws away too much. Conversely, displaying the entire Maven or Gradle log moves the original search task into a different page. The useful middle ground is an extracted diagnostic with supporting lines, a surrounding excerpt, and a link to the full console.

Extraction also has limits. The relevant lines may not have been retained, or the output may not match a recognized diagnostic format. In that case, showing the available excerpt and the evidence gap is more honest than manufacturing a precise failure category.

Bringing this workflow into Jenkins

Build Change Investigator implements this workflow on the Jenkins build page. It collects SCM changes and bounded, redacted failure evidence, then presents an investigation based on deterministic relationships. The core workflow does not require an AI provider.

The current implementation recognizes structured compiler diagnostics, Java exceptions, test failures, and API linkage errors when the retained evidence supports them. It ranks changes using direct source-path matches, explicit build-task module information, and weaker stage or configuration overlap. It does not traverse the full Pipeline execution graph or establish checkout ownership for every stage.

Its first-bad calculation requires adjacent build numbers, matching specific failure signatures, and FAILURE results back to a successful build. Missing builds, unavailable signatures, different failures, and intermediate results such as UNSTABLE or ABORTED leave the boundary unknown. The history inspection is bounded rather than an unlimited search.

Sometimes the automatic window is not the question an engineer needs to ask. Build-to-build comparison lets the engineer choose two completed builds of the same accessible job and inspect their evidence in the same view. The baseline must precede the target, and the supported comparison window is bounded to 100 build numbers.

Explicit comparison uses the same evidence presentation with a selected build window.

Similar past failures provide another lead. A matching retained signature from before a successful boundary may be worth revisiting. It is historical context, not evidence that the earlier and current failures share a cause. There may be a useful old investigation to read; there may also be no recorded resolution.

Native Jenkins Build History remains available alongside the investigation. Copy investigation produces a bounded text summary for a handoff, including the evidence and suggested checks. Neither feature requires replacing the existing build navigation or asking someone else to reconstruct the entire case from console links.

Keep the investigation verifiable

Optional AI interpretation can suggest an explanation and checks using the collected evidence. An authorized user explicitly runs it; opening the page does not invoke a provider. Before an AI request, the plugin limits the evidence and applies best-effort secret redaction. That is a protection, not a guarantee that every sensitive string will be recognized.

For a verified first-bad case, the interpretation receives the narrowed changes while the failure signal and build metadata remain identified as belonging to the current build. That distinction prevents a later failure from being presented as though its log came from the first bad build.

The interpretation should be read after the observed facts and their deterministic relationships. A fluent explanation cannot establish a dependency version that was not captured or prove which runtime artifact was loaded. If a provider fails, the engineer still has the deterministic investigation to work from.

For the payments example, a useful handoff is modest and concrete: #869 succeeded; the matching failure sequence starts at #870; the narrowed changes include a file in the failing module; the current diagnostic is NoSuchMethodError; inspect the module diff and loaded dependencies first. That gives the next engineer something to test.

The goal is not to replace Console Output or claim a root cause automatically. It is to give the engineer a better starting point: what last worked, what changed, where the matching failures began, and what evidence is worth checking first.

Build Change Investigator is available in the Jenkins plugin directory, and the source and issue tracker are available in the official Jenkins repository.

Build	Result	Retained failure evidence
#869	SUCCESS	Successful baseline
#870	FAILURE	Specific payments API failure signature
#871	FAILURE	Same signature
#872	FAILURE	Same signature
#873	FAILURE	Same signature; current investigation

Build

Result

Retained failure evidence

#869

SUCCESS

Successful baseline

#870

FAILURE

Specific payments API failure signature

#871

FAILURE

Same signature

#872

FAILURE

Same signature

#873

FAILURE

Same signature; current investigation

GSoC 2026 Final term: AI Chatbot to Guide User Workflow

2026-09-13T16:43:23+00:00

Hi everyone 👋,

I’m Daniele, the Google Summer of Code 2026 contributor who worked this summer on creating the AI Chatbot to Guide User Workflow plugin.

The extended period of my project is coming to an end, and I want to share a bit about this brand-new plugin and my journey through GSoC.

About the Project

The plugin integrates an agent-powered chatbot directly into the Jenkins interface. This tool is invaluable for both beginners who need guidance navigating the software and experts who want to quickly troubleshoot a failed build.

The agent can perform a variety of tasks, including: * Searching the Jenkins documentation and Discourse topics. * Reading Jenkins context data, such as failed build logs or job configurations.

During the first part of GSoC, I worked on the components surrounding the agentic logic: the Data Pipeline, Frontend UI, Hybrid Retrieval, and the communication layer between the frontend and backend.

Second part of GSoC

In this second phase of GSoC, I focused on building the core agent logic and the tools the agent uses to gather Jenkins context information.

The agent logic is powered by LangGraph, and I found that a 20-billion parameter model is more than enough for our needs. In fact, using gpt-oss-20b, the agent can seamlessly search through the logs of a failed build, analyze job configurations, and inspect workspace trees and files to retrieve general Jenkins information. (You can read more about the agent logic here).

I also implemented two advanced, optional features that require more computational resources than the baseline setup:

Reranking: Allows the use of a specific reranker model to reorder the documents retrieved from the vector database, maximizing the relevance of the context.
Contextual Retrieval: A technique introduced by Anthropic that significantly improves RAG (Retrieval-Augmented Generation) accuracy. You can read more about it here and in the official Claude cookbook.

Additionally, both evaluation tests and observability were integrated into the project. This infrastructure ensures that future developers can easily troubleshoot the agent logic and evaluate any new features added to the agent. (Read more about evaluation here).

Finally, I wrapped up my GSoC journey by thoroughly documenting the project (available on the official documentation site) and implementing End-to-End (E2E) Cypress tests using Docker. These tests are crucial to ensure that the entire architecture works and all components communicate exactly as expected.

My contributions

Here is the list of the Pull Requests I’ve worked on during the program:

The plugin’s future

The plugin will be published soon so that anyone can test it out on their machine. Setup is very straightforward, and I’ve published a guide on how to quickly install and configure it: AI Chatbot Workflow Quick Installation Guide.

In the future, I would love to see the following features added:

Frontend UI Markdown support: Currently, the frontend displays Markdown as plain text. Implementing a proper rendering of Markdown text will highly improve readability.
"Human-in-the-loop" features: It is fantastic that the chatbot can tell us how to do and fix things, but it would be even better if it could perform actions for us upon request. Changing a specific setting or updating a Jenkins pipeline file automatically without the need to do it manually would be an incredible time-saving feature.

Acknowledgements

Over the past few months, I’ve had the privilege to work for a very important Open Source organization, assisted by my fantastic mentors: Kris Stern, Shivay Lamba, and Chirag Gupta, who guided me through the process of creating this incredible new plugin.

I’m very grateful to the Jenkins Community for this opportunity, and I’m truly happy to be a part of it.

See you soon!

More about me

Here you can find my contact details:

Jenkins + OpenChoreo: Adopt a modern Internal Developer Platform (IDP) Without Replacing Your CI System

2026-09-13T16:43:23+00:00

Your Jenkins setup represents a decade of institutional knowledge: countless custom pipelines, shared libraries, and specialized build agents. Yet when platform engineering enters the conversation, most IDP demos ignore this investment entirely. This article is for platform engineers and DevOps leads who run Jenkins at scale and are evaluating an internal developer platform. It lays out a different path: add one stage to your pipeline, and keep everything else exactly where it is – along with a clear model of the CI/platform boundary, a Jenkinsfile stage you can copy directly, and an honest account of what the trade costs.

The most common misconception about platform engineering is that adopting an IDP means throwing away your CI tooling. It doesn’t have to. Here is where OpenChoreo can help with your workflow without altering your CI habits. OpenChoreo’s external CI integration lets teams keep their Jenkins pipelines, plugin ecosystem, and institutional knowledge, while layering on environment management, self-service workflows, multi-cluster deployment, and observability – all via a single API call at the end of the build stage.

The Argument

CI is a core part of the platform experience. But the real question is whether the platform should be tightly coupled to one specific CI implementation, and the answer is no. With the right abstraction at the integration point, teams keep Jenkins or run something else entirely, and the developer experience the platform delivers stays the same.

To do its job, the platform doesn’t need your build graph, your test matrix, or your pipeline DSL. It needs exactly one fact: this image, for this component, is ready.

Everything before that fact is CI implementation, that’s Jenkins’s half of the experience, and it stays exactly as it is. Everything after it is the platform’s half. From there, "adopt an IDP" no longer means "replace your CI". It means only one thing: add one stage to your pipeline.

What Jenkins Teams Fear (and Why)

The concern is real: when a platform team standardises on an IDP, what the Jenkins user hears is that hundreds of pipelines, the shared libraries, agents, etc. that took a long time to design and implement, are about to be thrown away.

That fear comes from how these platforms are usually demoed. Almost every IDP demo starts at git push and ends at "running in production", which puts CI inside the platform the entire length of the demo. That’s an accurate description of the experience for a team starting from scratch using the platform’s built-in CI. It is not, however, an architectural requirement of the platform. The two systems can be decoupled, and establishing that decoupling is the core focus of this article.

The Boundary

So if the platform does not take over CI, where exactly does CI end and the platform begin? Here is the split.

One artifact reference crosses the boundary. That is the whole contract.

Figure 1. From Jenkins build to Production

The line sits here because the two columns change at different speeds, have different owners, and fail in different ways. Build logic changes per team, per language, per repo. Environments and promotion policy change per organisation. Bundling the two together is what makes platform adoption feel like a CI migration. Keep them separate, and it never has to be one.

What stays in Jenkins

What moves to the platform

SCM triggers, build agents, shared libraries

Environments and promotion

Test orchestration, the plugin ecosystem

Per-environment config and secrets

Build credentials, pre-build approvals

Multi-cluster placement

Build provenance and logs

Runtime observability, self-service catalog

The stage you need to add

OpenChoreo is an open-source internal developer platform that runs on Kubernetes. It owns the right-hand column of the table above: environments and promotion, per-environment configuration and secrets, multi-cluster placement, and a self-service portal with runtime observability, a layer your platform team operates over your clusters. The unit it deploys is a Workload: a small record naming a component and the image that should run for it. Registering that Workload from your pipeline is the entire integration, and the pattern applies to any platform with a similar API.

If your pipeline already builds and pushes an image, the diff is small: get a token, then register the workload. Here’s what that looks like with OpenChoreo as the platform.

One-time setup

On the platform side, create a service account – an OAuth2 client with the client_credentials grant, scoped so it can only register workloads.

If you are following the quick start, that account already exists. The installer registers a Workload Publisher client in the bundled Thunder identity provider and binds it to a workload-publisher role. The defaults are:

Confirm it works before wiring up Jenkins — this should return an access token:

curl -X POST "http://thunder.openchoreo.localhost:8080/oauth2/token" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=openchoreo-workload-publisher-client" \
  --data-urlencode "client_secret=openchoreo-workload-publisher-secret"

This is a shared development credential — it is the same account OpenChoreo’s own in-cluster build workflow authenticates as — so it is fine for a local trial and nothing more. For anything shared, create your own client in the Thunder console (http://thunder.openchoreo.localhost:8080/console, admin / admin) as a Backend Service application, then bind it to a role with a ClusterAuthzRoleBinding: the shipped binding matches the default client’s sub claim, so a new client inherits nothing. The Workload Publishing Credentials guide covers that setup, and Authorization lists the shipped roles and bindings.

Then store three values as ordinary Jenkins credentials:

workflows-credentials — the client ID and secret
thunder-url — the token endpoint of the identity provider (Thunder ships with OpenChoreo, but any OAuth2 IDP works)
openchoreo-api-url — the platform API URL

The external-CI docs cover this step by step; we’ll walk through the complete setup in the next post in this series.

Worth knowing before you file the security review: the service account’s workload-publisher role grants exactly workload:create, workload:update, workload:view, workflowrun:view, and workflowrun:update and nothing else. The two workflowrun actions are there for OpenChoreo’s built-in build workflow, which annotates its own run - an external pipeline never needs them, so a dedicated client can be bound to a workload-only role. If the Jenkins credential ever leaks, the blast radius is "can register an image for this component’s workload". It cannot promote anything, touch environment configuration, or reach the clusters. We verified this the direct way: the same token that had just registered our workload got an HTTP 403 when it tried to create a staging release binding.

The stage below isn’t pseudocode: it ran on a real Jenkins (2.541.1) against a live OpenChoreo cluster, twice in a row, so the second build exercises the update path. NAMESPACE, PROJECT, COMPONENT, and IMAGE come from the surrounding pipeline; the credentials are standard Jenkins credentials.

stage('Register workload with OpenChoreo') {
    steps {
        withCredentials([
            usernamePassword(
                credentialsId: 'workflows-credentials',
                usernameVariable: 'CLIENT_ID',
                passwordVariable: 'CLIENT_SECRET'
            ),
            string(credentialsId: 'thunder-url', variable: 'THUNDER_URL'),
            string(credentialsId: 'openchoreo-api-url', variable: 'OPENCHOREO_API_URL')
        ]) {
            sh '''
                set -eu

                # Jenkins masks the credentials it injected, but NOT the token
                # derived from them -- keep it out of the build log.
                set +x

                # 1. Exchange client credentials for an access token.
                TOKEN=$(curl -sf -X POST "${THUNDER_URL}/oauth2/token" \
                  -d "grant_type=client_credentials" \
                  -d "client_id=${CLIENT_ID}" \
                  -d "client_secret=${CLIENT_SECRET}" \
                  | jq -r '.access_token')

                # 2. Build the Workload payload.
                WORKLOAD_NAME="${COMPONENT}-workload"
                cat > workload-cr.json <<EOF
{
  "metadata": { "name": "${WORKLOAD_NAME}", "namespace": "${NAMESPACE}" },
  "spec": {
    "owner": { "projectName": "${PROJECT}", "componentName": "${COMPONENT}" },
    "container": { "image": "${IMAGE}" }
  }
}
EOF

                # 3. Create the Workload; on HTTP 409 fall back to PUT.
                #    The first build creates it; every build after that updates it.
                CODE=$(curl -s -o resp.json -w '%{http_code}' -X POST \
                  "${OPENCHOREO_API_URL}/api/v1/namespaces/${NAMESPACE}/workloads" \
                  -H "Authorization: Bearer ${TOKEN}" \
                  -H "Content-Type: application/json" \
                  -d @workload-cr.json)

                if [ "${CODE}" = "409" ]; then
                  curl -sf -X PUT \
                    "${OPENCHOREO_API_URL}/api/v1/namespaces/${NAMESPACE}/workloads/${WORKLOAD_NAME}" \
                    -H "Authorization: Bearer ${TOKEN}" \
                    -H "Content-Type: application/json" \
                    -d @workload-cr.json -o resp.json
                elif [ "${CODE}" -lt 200 ] || [ "${CODE}" -ge 300 ]; then
                  echo "Workload registration failed (HTTP ${CODE}):"
                  cat resp.json
                  exit 1
                fi
            '''
        }
    }
}

Using the OpenChoreo CLI

Alternatively, the OpenChoreo CLI (occ) completes registration in five commands. occ apply checks whether the workload exists and creates or updates it, so the 409 fallback disappears; API errors come back as readable messages with a non-zero exit code, so no jq is needed; and the CLI reads its credentials from environment variables and never prints the token, so the set +x guard is unnecessary. This sequence was verified on the same Jenkins instance:

export HOME="${WORKSPACE}"   # occ stores its login under ${HOME}/.openchoreo
occ config controlplane update default --url "${OPENCHOREO_API_URL}"
occ login --client-credentials   # reads OCC_CLIENT_ID / OCC_CLIENT_SECRET
occ workload create --descriptor workload.yaml \
  -n "${NAMESPACE}" -p "${PROJECT}" -c "${COMPONENT}" \
  --image "${IMAGE}" -o workload-cr.yaml
occ apply -f workload-cr.yaml

Notice what the stage does not contain: the environment names, kubectl, cluster credentials, manifests, and promotion logic. The pipeline does not need to know how many environments exist.

At the scale this post’s audience runs - hundreds of pipelines - you wouldn’t paste this stage into each Jenkinsfile by hand. Wrap it as a step in your global shared library, and the per-pipeline diff shrinks to one line, something like openchoreoRegister(image: env.IMAGE). Rolling the integration out, or changing it later, becomes a library release instead of a hundred pipeline edits. We’re leaving the wrapper itself as packaging; the API call inside it is exactly the stage above. The point is that Jenkins already has the distribution mechanism for this, and it is one your team uses today.

Value Default on a quick-start install

Thunder token endpoint

http://thunder.openchoreo.localhost:8080/oauth2/token

OpenChoreo API

http://api.openchoreo.localhost:8080

Client ID

openchoreo-workload-publisher-client

Client secret

openchoreo-workload-publisher-secret

What you get back

The exact image Jenkins built, promoted unchanged through development → staging → production.

Figure 2. Component Deployment View in OpenChoreo Backstage Portal.

Promotion becomes a platform-level operation rather than a pipeline stage. Engineers or release managers promote components through the UI portal or via a single CLI command:

occ component deploy <component> --to staging

The exact build Jenkins produced was promoted through all three environments and served the same content in each, with Jenkins uninvolved after the registration call.

Build-once, promote-many works because the line sits where it does: promotion has its own access control and doesn’t inherit from Jenkins. Deploy the pipeline to each environment directly instead, and you’re left with two options: rebuild per environment, or teach Jenkins your organization’s entire promotion policy.

The Trade-Offs

Access and Security: Jenkins requires a service account and network access to the platform API, introducing a new credential to manage and an additional dependency in the build path.
Shift in Deployment State: Operational state shifts away from the pipeline. For teams accustomed to viewing "the Jenkins job as the deploy," this represents a structural shift in workflow tracking.
Rollback Mechanics: Re-running a Jenkins job builds and registers a new artifact. Rollbacks are executed as platform actions targeting previously validated releases.

The migration is incremental by design: one component, one extra stage, one pipeline you don’t otherwise touch. Nothing about it is a cutover. By decoupling the build from the deployment, you gain the benefits of a modern platform without the friction of a forced migration, proving that progress can be achieved through evolution rather than revolution.

If you want to try this yourself, the OpenChoreo quick start gives you a local cluster with the three environments used above. In the next post in this series, we will walk through the complete setup end to end — the service account, the credentials, the component, and surfacing Jenkins build status inside the portal.

Links:

OpenChoreo Repository: https://github.com/openchoreo/openchoreo

OpenChoreo external-CI integration docs: https://openchoreo.dev/docs/platform-engineer-guide/workflows/external-ci

Plugin of the Month – September 2026: ORAS Artifact Manager

2026-09-13T16:43:23+00:00

Welcome back to the Plugin of the Month series, where we highlight useful and impactful tools from the Jenkins ecosystem.

This September, we’re featuring a plugin that rethinks where your build artifacts actually live: the ORAS Artifact Manager Plugin.

What is the ORAS Artifact Manager Plugin?

By default, Jenkins stores archived artifacts and stashes on the controller’s local disk (or on whatever storage backend an artifact manager plugin provides). The ORAS Artifact Manager Plugin takes a different approach: it stores them in any OCI-compliant registry, using ORAS (OCI Registry As Storage).

OCI registries were originally built to distribute container images, but the OCI ecosystem has since standardized on storing arbitrary content — SBOMs, Helm charts, signatures, and now Jenkins build artifacts — as regular OCI artifacts.

Once configured, every archived file and every stash produced by your jobs is pushed to the registry of your choice instead of piling up on the Jenkins controller’s disk:

From the build page, artifacts look exactly like artifacts always have — you don’t lose the familiar Jenkins UX, you just change where the bytes are stored.

Built on ORAS and the ORAS Java SDK

The plugin doesn’t talk to registries directly. It relies on a dedicated ORAS Java API Jenkins plugin, which in turn bundles the official ORAS Java SDK.

This layering matters:

ORAS defines the client tooling and conventions for pushing/pulling arbitrary artifacts to OCI registries, on top of the OCI Distribution and OCI Image spec.
The ORAS Java SDK is a CNCF ORAS sub-project library that implements those conventions natively in Java.
The ORAS Artifact Manager Plugin builds Jenkins' artifact and stash storage model on top of that SDK.

Because the underlying protocol is just OCI, any registry that speaks the OCI Distribution Spec works: Docker Registry, Harbor, Zot, GitHub Container Registry, Artifactory, and others.

How Artifacts Are Structured in the Registry

This is the part that’s genuinely interesting if you’re curious about OCI internals, and not just "another storage backend."

The plugin maps each Jenkins job to an OCI repository, sanitizing the name in the process (for example folder/My Job becomes folder/my-job). For every build, it pushes a build root artifact, tagged with the build number, which acts as the anchor for everything produced during that build. Every archived file is then pushed as its own single-layer OCI manifest, linked back to that root artifact using the OCI 1.1 subject field — the same mechanism used for referrers like signatures or SBOMs on container images. Stashes follow a similar pattern, stored as tagged, gzip-compressed layers.

The two custom media types you’ll see on the manifests are:

application/vnd.io.jenkins.oras-artifact-manager.build.v1+json for the build root artifact
application/vnd.io.jenkins.oras-artifact-manager.file.v1+json for each individual archived file

Because files reference the build root through subject instead of a hand-rolled index file, the plugin can discover every artifact for a build with a single call to the registry’s referrers API.

You can see this structure yourself with the oras CLI. Given a build root tagged 13, asking the registry what refers to it:

$ oras discover -o tree localhost:5000/test:13

localhost:5000/test:13
└── application/vnd.io.jenkins.oras-artifact-manager.file.v1+json
    ├── sha256:2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7a
    ├── sha256:9e58a1ce0ff0aad2adf3f18e6c92e58a17d3f4b5c6a7891234567890abcdef0
    └── sha256:d1f2c3a4b5e6d7c8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2

Each of those digests is an independent manifest carrying a single layer (the file’s content) plus annotations that preserve the metadata Jenkins cares about — the archived path, the creation timestamp, and so on. A registry UI that understands OCI referrers, like Zot, will show exactly that relationship when you inspect the build root artifact:

Notice the annotations: io.jenkins.oras-artifact-manager.path tells you which archived file this manifest corresponds to, and standard OCI annotations like org.opencontainers.image.created come along for free.

Worth Keeping in Mind

The plugin is still in beta, and so is the underlying ORAS Java SDK — APIs on both sides may still change before things settle. If you’re evaluating it, start with non-critical jobs, keep an eye on the GitHub repository for updates, and report anything unexpected through its issue tracker.

Looking Ahead

If your Jenkins controllers are drowning in archived artifacts, or you already run an OCI registry for your container images and would rather not maintain a second storage system just for build outputs, the ORAS Artifact Manager Plugin is worth a look.

Stay tuned for next month’s Plugin of the Month, and feel free to suggest plugins you’d like to see featured!

Daily Life as a Jenkins Administrator

2026-09-13T16:43:23+00:00

Introduction

Hi, my name is Mark. I am a Jenkins administrator, and I want to share some of my daily experiences using and maintaining Jenkins. I hope you enjoy it.

Environment and setup

We have two Jenkins servers, production and quality. Both run on a commercially supported Linux distribution, normally on the latest LTS version, with around 200 plugins installed. Production runs more than 6,000 builds every day and supports more than 1,000 users and 200 agents running Windows and Linux. On this note, most of the agents are maintained by the departments themselves. We offer guidance and also (limited) support.

In addition to the Jenkins servers, we provide every Jenkins user with access to Kubernetes agents. These agents use a special build image that we maintain. The image includes and configures various tools (Java, .NET, Python, Node.js) and services (proxies and certificates). Users can therefore get started with their multibranch pipelines quickly.

We also provide template repositories for different languages, including examples of how to build and deploy an application to a Kubernetes cluster. Users can use these repositories to get started quickly.

Finally, we have a shared library with common methods for accessing our tools and setting up tool-specific steps.

LTS and maintenance

Our maintenance is announced one week in advance. Between the announcement and the date, we test the changes on quality with different jobs and coordinate with a few departments on additional testing. Security advisories with an impact on our environment are addressed within 36 hours. Breaking changes in Jenkins or its plugins, such as a Java 21 upgrade, are announced further in advance because of their complexity:

Java 21 upgrades: announced three months in advance
Jenkins plugin updates affecting only a few users: announced one week in advance

Tickets and daily life

We have a ticketing system for our users to report issues or request support. Most tickets actually concern access. We have guides for these requests, but it seems they are hidden well. The remaining tickets involve pipeline support, debugging connections to other tools, evaluating new plugins, and supporting user-managed agents.

Feedback & outlook

Believe me or not but I have content for a few more posts, so I hope you had fun and will have fun in the future. I plan to post a new blog every two weeks, so stay tuned for more content.

If you have feedback or questions, please use the comment section below.

Greetings, Mark

GSoC 2026 Endterm - Plugin Modernizer Stats Visualization

2026-09-13T16:43:23+00:00

Hello everyone,

This blog showcases the work done on the Plugin Modernizer Stats Visualization project during Google Summer of Code 2026. For a detailed description of the project, please refer to the project page.

About the Project
Phase 1
Phase 2
Challenges and Learnings
Next Steps
Acknowledgements
Useful Links

About the Project

The Plugin Modernizer Tool automates the modernization of Jenkins plugins using OpenRewrite recipes, creating pull requests with the results. As part of GSoC 2025, a metadata repository was established that stores raw modernization metadata in JSON/CSV format.

My GSoC 2026 project, Plugin Modernizer Stats Visualization, builds a static visualization site that consumes this metadata, consolidates it into a structured format and presents dashboards alongside per-plugin and per-recipe report pages. The goal was to give plugin maintainers, modernizer authors, new contributors and the infra team a single place to understand modernization health at a glance without manually browsing hundreds of plugin directories.

The diagram below shows how the different pieces of the ecosystem fit together:

Phase 1

By the midterm, we accomplished the following milestones:

Data Pipeline (ETL): A GitHub Actions workflow in metadata-plugin-modernizer validates raw modernization data, runs a Python consolidation script to produce a single report.json and deploys it via GitHub Pages.
Dashboard (Home Page): Summary stat cards, migration status donut chart, recipe performance bar chart, migration timeline trend, and tag distribution visualization.
Plugin List Page: A searchable table of 400+ plugins with status badges, migration ratios, last-updated dates, and links to plugin pages and GitHub repositories.

Check out the live demo and my midterm blog post for more details on the first half of the coding period.

Phase 2

In the second half of GSoC, the focus shifted from foundational pages to drill-down reports, polish and production readiness. The result is a fully navigable site where users can move from a high-level overview down to individual plugins and recipes.

Dashboard

The home page brings together the key metrics from across the modernization effort : total plugins, migrations, successes and failures alongside charts that reveal trends over time and highlight which recipes need attention.

Plugin List Page

The plugin list page displays all plugins that have been processed by the Plugin Modernizer Tool. Each row shows the plugin name, overall migration status (All Passed, All Failed, Mostly Passed, Mostly Failed), the success-to-failure ratio, the last updated date and quick links to the plugin’s detail page and GitHub repository. The table is searchable and filterable, making it easy to find a specific plugin or scan for ones that need attention.

Per-Plugin Detail Pages

Clicking into any plugin opens a dedicated detail page with a complete picture of that plugin’s modernization history. For example, the page for the ansible plugin shows:

A header with the plugin’s overall status, repository link, branch, last updated date and merged PR count.
Summary stat cards for total migrations, successes and failures.
A migration timeline chart that visualizes when recipes were applied and whether they succeeded or failed.
A recipe breakdown table listing every recipe applied to the plugin, along with applied, success and failed counts and per-recipe status.
A PR history section with links to the pull requests generated by the modernizer.
A failed migrations table surfacing error details for any recipes that did not succeed.

Recipe List Page

The recipe list page displays all recipes that have been applied across the plugin ecosystem. Each row shows the recipe name, how many plugins it was applied to, the overall success rate and a link to the recipe’s detail page. This view helps recipe authors quickly identify which recipes are performing well and which ones may need fixes or improvements.

Per-Recipe Detail Pages

Each recipe has its own detail page with stats scoped to that recipe. For example, the page for the AddCodeOwner recipe shows:

A header with the recipe’s fully qualified name and overall success rate.
Summary stat cards for total applications, successes, failures and success rate percentage.
An application status donut chart breaking down success, failure and other outcomes.
An application timeline chart showing when the recipe was applied over time.
An affected plugins table listing every plugin the recipe was run against, along with per-plugin status and date.

Stretch Goal: CLI Command Snippets

As a stretch goal, I added copy-paste CLI command snippets on both the per-plugin and per-recipe detail pages. These snippets show the exact plugin-modernizer command needed to run a dry-run (or apply) a recipe on a specific plugin, lowering the barrier for maintainers who want to reproduce or retry a modernization locally. Users can expand a dropdown to see per-recipe commands for a given plugin, or per-plugin commands for a given recipe, and copy any command with a single click.

UI/UX, Theming and Reliability

Beyond the core pages, several improvements went into making the site production-ready:

Jenkins-aligned theming using jenkins-io-components for shared navbar and footer, with a color palette consistent with the Jenkins visual ecosystem.
Error boundaries and error pages for graceful handling of missing data, network failures and invalid routes.
Skeleton loaders on dashboard, list and detail pages so the UI feels responsive while data is being fetched.

Testing

The project now has 32 test files with 303 passing tests covering pages, components, hooks and utility functions using Vitest and Testing Library. A GitHub Actions CI pipeline runs linting, formatting, build and test checks on every pull request. The site is deployed automatically to GitHub Pages on every merge to the main branch.

Documentation

The repository README includes setup instructions, a description of the data flow and references to the related Plugin Modernizer and metadata repositories, making it straightforward for new contributors to get started.

Challenges and Learnings

Designing a consistent data model that could power both plugin-level and recipe-level views from a single report.json was one of the bigger technical challenges. The consolidated report needed to be rich enough for detailed drill-down pages while remaining small enough to fetch quickly in the browser. Working closely with my mentors on the schema in metadata-plugin-modernizer early on helped avoid rework later.

Performance was another consideration with 431 plugins and 21 recipes, list pages needed virtualization and careful chart rendering to stay smooth. Using react-window for the plugin and recipe tables and lazy-loading chart data on detail pages kept the experience snappy even on slower connections.

Finally, coordinating changes across two repositories (metadata-plugin-modernizer for the ETL pipeline and plugin-modernizer-stats for the UI) taught me a lot about planning cross-repo work, writing clear PR descriptions and keeping both sides in sync through regular mentor syncs.

Next Steps

While the core deliverables are complete, the following areas represent the clearest next steps for making the modernization effort more targeted and effective:

Plugin Health Score Page

Goal: Add a dedicated page that displays a health score for each plugin, similar to the existing score on the Jenkins Plugin Index (e.g., ansible-tower health score).
Why it matters: Today, the stats site shows what happened during modernization — which recipes ran, which PRs were opened and whether they succeeded. A health score page would show where a plugin stands overall — surfacing gaps in documentation, dependencies, security advisories, adoption and other factors that affect maintainability.
Expected outcome: Plugin maintainers and contributors could open a single page, see a plugin’s health at a glance and immediately understand which modernization recipes would have the highest impact. This turns the stats site from a historical report into a prioritization tool helping the community focus modernization efforts on plugins that need it most.

AI-Assisted, Plugin-Specific Recipe Recommendations

Goal: Explore integrating AI technologies to analyze a plugin’s modernization history and recommend specific, plugin-level recipes tailored to that plugin’s current state.
Why it matters: Not every plugin needs the same set of recipes. Running all 21 recipes blindly is inefficient; some plugins may only need a Java version upgrade, while others need dependency migrations or CI workflow updates. By learning from patterns in the existing metadata (which recipes succeeded, which failed and in what order), an AI-assisted layer could suggest the most relevant next steps for each plugin.
Expected outcome: Instead of a maintainer guessing which recipes to apply, the tool would surface a ranked list of recommended recipes with reasoning, improving the accuracy and effectiveness of the modernization process and reducing failed migration attempts.

Other Enhancements

Add deeper filtering and sorting options on list pages (e.g., filter plugins by tag or recipe).

Explore embedding or linking the stats from stats.jenkins.io for broader discoverability.
Add export options (CSV/JSON) for plugin and recipe reports.
Continue expanding test coverage as new features are added and the dataset grows beyond 431 plugins.

Acknowledgements

A huge thank you to my mentors, Valentin Delaye, Kris Stern, Sridhar Sivakumar and Raunak Madan, for their constant support, refining the approach and timely reviews throughout the journey. They conducted sync meetings twice a week, were always reachable on Slack and actively reviewed my pull requests — that made all the difference.

I’d also like to thank the organization admins for always checking in and offering help.

This project builds on the work started by Sridhar Sivakumar in GSoC 2024, Using OpenRewrite Recipes for Plugin Modernization, and improved by Raunak Madan in GSoC 2025, Improving Plugin Modernizer. I’m grateful to continue that lineage.

Finally, thank you to the Jenkins community for being welcoming and supportive throughout GSoC 2026.

Useful Links

Announcing a Contributor Summit Virtual Event (September 11, 2026)

2026-09-13T16:43:23+00:00

We are excited to announce the Contributor Summit Virtual Event happening on September 11, 2026.

The Contributor Summit is an opportunity for Jenkins contributors, users, and enthusiasts to come together, share knowledge, and collaborate on the future of Jenkins. Mark your calendars and join us for a day of insightful sessions, networking, and community building.

Event Details

The summit will be entirely online. Join us for all the sessions or just a few.

Jenkins Contributor Summit 2026: The virtual hackathon

We will be hosting a virtual hackathon on September 11, 2026, from 08:30 to 19:30 CEST. The event will be conducted online, allowing participants from around the world to join and contribute.

It will be structured into two main blocks:

Morning Block: The APAC-EMEA Connection

Focus: Catching APAC before they sign off for the weekend.

The “Moderator’s Siesta” (12:30 – 15:00 CEST)

The bridge remains open for EMEA contributors, but the formal moderation pauses.

Afternoon Block: The EMEA-Americas Connection

Focus: Bringing the US/LATAM online and finishing what started in the morning.

Time (CEST)

Session

Activity