Jenkins is not behaving like a legacy CI server coasting on habit. ToolVitals measured 13 release events in 30 days, 22 GitHub releases in 90 days, a 100 health score, a 100 shipping score, and a 100 ToolVitals score. The interesting part is not just the release cadence. The recent first-party material points in three directions at once: hardening Jenkins core, making CI failures less noisy, and adding AI-assisted help without letting the AI make unsafe decisions.

What Jenkins says it is now

The official Jenkins site still gives the clearest short version: Jenkins is an open source automation server for building, testing, deploying, and automating software. The site emphasizes scale, plugin coverage, a web configuration interface, distributed work across machines, and packages for Windows, Linux, macOS, and other Unix-like systems.

The GitHub repository says the same thing in plainer engineering terms. It describes Jenkins as a Java automation server, commonly used to run tests, build artifacts, publish or deploy software, schedule jobs, and automate maintenance work. The repository also says Jenkins ships official distributions as WAR files, Docker images, native packages, and installers.

That matters because Jenkins is not trying to win only on one narrow CI workflow. It is still positioned as a general automation control plane. The plugin architecture is the product surface. The official site says Jenkins provides hundreds of plugins, while the GitHub repository describes over 2,000 plugins. ToolVitals should treat those as first-party positioning claims, not measured plugin quality.

Jenkins is OSI-approved open source in the ToolVitals payload, with an MIT license signal. No hosted pricing is tracked here. That is a major distinction from commercial DevOps platforms where health signals can be split between a public repository and a private hosted service. For Jenkins, the public project is the product center.

The notable signal is conservative modernization

The recent Jenkins posts do not read like a project chasing fashion. They read like a mature project trying to modernize without breaking the thing people already depend on.

The Smart Retry announcement is the cleanest example. The feature targets transient CI failures: evicted Kubernetes agents, interrupted Git fetches, artifact repository outages, and similar failures where a manual rebuild often works. The design is intentionally narrow. The smartRetry Pipeline step captures the error and a bounded slice of console output, classifies the failure into deterministic categories, checks the active retry profile, then logs the decision.

The boundary is the point. The announcement says Smart Retry does not use AI-based failure classification. It does not retry UNKNOWN by default. It does not retry compilation failures, Pipeline logic failures, user aborts, or deployment-style failures in the default policy. The current built-in profiles include conservative and infra, with conservative retrying only AGENT_LOST and SCM_TRANSIENT, and infra adding network, artifact repository, and identity provider transients.

That is a strong engineering choice. CI retries are dangerous when they hide real failures. Jenkins is choosing explainable retry policy over a vague promise that the system will figure it out. Teams that have been burned by flaky pipelines should care more about that design than about the word smart.

The 2.572 changelog points in the same direction. The official changelog dated July 6, 2026 includes a password complexity rule extension point, UI refinements, and multiple deserialization hardening changes, including expected-type checks for deserialized collection elements and prohibiting deserialization of Object fields by default. Those are not flashy features. They are the kind of changes that matter in a long-running automation server exposed to plugins, jobs, credentials, and admin workflows.

The LTS changelog for 2.568.1 adds another maintenance signal. It lists Spring Security and Spring Framework updates, a bundled Script Security Plugin update, UI fixes, and a note that Windows 2019 controller images were dropped from that release. ToolVitals should not overstate what that means, but it shows active dependency upkeep and platform boundary management in the stable line.

The AI work is real, but not the whole story

The July 10 GSoC posts show that Jenkins is investing in AI assistance from multiple angles. One post describes continued work on an AI-powered chatbot for quick access to Jenkins resources. The midterm milestone is not a chatbot demo. It is an LLM-as-Judge CI evaluation pipeline using a fixed golden dataset, generated chatbot responses, and DeepEval judge metrics. The post reports current evaluation scores above a 0.85 benchmark, with contextual recall around 0.92 and faithfulness and answer relevancy around 0.88.

Use those numbers carefully. They come from a GSoC project update, not from ToolVitals measurement. They still matter because they show how the Jenkins community is trying to review AI changes. The post frames evaluation as the base that makes retrieval and diagnosis features safer to build and review.

A second July 10 GSoC post goes deeper into the user-facing chatbot workflow. It describes data retrieval from Jenkins docs, plugin docs, Reddit, and Discourse, then processing, chunking, embedding, and storage in Qdrant. It uses hybrid retrieval with semantic search and BM25. The frontend is described as React, Vite, TypeScript, and MUI, with a side panel inside Jenkins. The Jenkins Controller acts as a proxy to a FastAPI backend, checks a Jenkins CSRF token, and attaches a temporary JWT.

That is a concrete architecture, not just a roadmap sentence. It also raises the questions an engineering lead should ask before adopting it: where does the backend run, how is user context stored, what data leaves Jenkins, what is retained in PostgreSQL, and how do admins govern the uploaded context such as job config.xml, pipeline definitions, and failed run logs?

A third GSoC post covers Plugin Modernizer Stats Visualization. It describes a GitHub Actions ETL workflow, a consolidated report.json deployed through GitHub Pages, summary stat cards, charts, and a searchable table of all 431 plugins in that dataset. This is not directly Jenkins core, but it connects to a real operational problem: plugin migration is hard to manage when the project is huge and distributed.

The Jenkins.io Success Stories work points in the same direction. The contributor describes migrating the application from Gatsby to Vite, replacing a GraphQL-based data layer with direct YAML parsing, and cleaning 194 YAML files with linting and schema validation. That is website work, but it is also infrastructure work for a community project that depends on durable public documentation and contribution paths.

The pattern across these posts is useful. Jenkins is adding AI and modernization work around evaluation, retrieval, plugin migration visibility, and user guidance. At the same time, the Smart Retry announcement deliberately avoids AI for retry classification. That split is the real story. Jenkins is not treating AI as a universal answer. It is applying it where retrieval and guidance make sense, while keeping execution behavior deterministic where bad automation can waste compute or mask defects.

What ToolVitals measured

ToolVitals gives Jenkins a hot score of 226.7, a health score of 100, a shipping score of 100, and a ToolVitals score of 100, with data confidence at 100. The tracked GitHub repository has 25,648 stars. The payload records 22 GitHub releases in the last 90 days and 13 release events in the last 30 days.

Those numbers support a simple conclusion: Jenkins is active. This is not a quiet maintenance-only repository with an occasional patch. The recent event stream includes weekly and LTS releases, product updates, and multiple community project reports.

The release count also fits Jenkins’ documented release model. The GitHub repository says Jenkins has two release lines: Weekly for frequent releases with new features, improvements, and fixes, and Long-Term Support for an older line updated with backported fixes. The official download page surfaced by search describes the same split, with LTS baselines selected from regular releases and fix backports on a slower cadence.

Where can the numbers mislead? Release events do not prove a release is easy to upgrade. Stars do not prove current adoption growth. A 100 health score does not mean every plugin is healthy. Jenkins has a large plugin-driven surface area, so core vitality and plugin vitality are related but not identical.

The payload has null values for GitHub commits in 30 days and active contributors. That means this post should not claim a specific recent commit count or contributor count. It can say the project is shipping based on release and event metrics, but it cannot say how many individuals are actively committing from ToolVitals data.

Compared with Pulumi, Jenkins is almost tied on GitHub stars in this payload: Jenkins has 25,648, Pulumi has 25,422. Both have a 100 shipping score. Jenkins has 13 release events in 30 days, while Pulumi has 15. That makes Jenkins look less like an old incumbent and more like a peer in current DevOps shipping activity, at least by the ToolVitals signals available here.

ProxmoxVE Scripts has 28,922 stars and 30 release events in 30 days, so it is moving faster by release-event count. ClickHouse is in another category and shows 48,575 stars with 59 release events in 30 days. LangChain is far larger by stars at 141,504 and has 23 release events in 30 days. Those comparisons should not be read as direct product substitutions. They show that Jenkins is active enough to sit near fast-moving infrastructure and developer tools in the ToolVitals ranking, even if the jobs to be done are different.

The better comparison is Pulumi because both sit in DevOps. Pulumi’s momentum is not surprising for infrastructure-as-code. Jenkins matching it on shipping score and roughly matching stars is more interesting because Jenkins carries a much older architecture, a huge plugin footprint, and a large installed base that cannot absorb reckless change.

What the data does not tell you

ToolVitals sees public signals: releases, stars, release events, SSL and availability-style health signals, and the first-party material included in the payload. It does not see private Jenkins deployments. It does not know whether your controller upgrade will be painless. It does not know whether your exact plugin mix is maintained. It does not know user satisfaction, revenue, support burden, queue latency, build success rates, or whether a specific plugin works well under your workload.

A skeptical buyer or engineering lead should treat Jenkins as a serious option when control, extensibility, and self-hosted automation matter. The evidence here supports vitality, not simplicity. If your team wants a hosted CI product with fewer knobs, Jenkins may still be too much machinery. If your team needs deep customization, internal network access, plugin-level extensibility, and explainable automation policies, the recent Jenkins direction is encouraging.

A useful maintainer takeaway is different. The strongest recent work is the work that reduces operational ambiguity: deterministic Smart Retry logs, LLM evaluation pipelines, plugin modernization dashboards, stricter data validation for success stories, and security-oriented core changes. Keep making those artifacts easy to find from the main site. The project is doing meaningful modernization work, but buyers will miss it if it is scattered across blog posts, release drafts, plugin pages, and project updates.

Recommendation

If your team already runs Jenkins, the current signal says do not treat it as abandoned infrastructure. Review the 2.568.1 LTS notes, inspect the 2.572 weekly changelog for upcoming core changes, and evaluate Smart Retry on a small set of idempotent, infrastructure-sensitive Pipeline steps. The first target should be builds that fail from agent loss, SCM interruptions, or temporary artifact repository outages, not broad retry wrappers around entire pipelines.

If your team is choosing a CI/CD platform from scratch, evaluate Jenkins when you need self-hosted control, plugin depth, and deterministic automation over a long-lived automation server. Do not choose it because AI chatbot work exists. Choose it if the combination of open source licensing, active release flow, conservative failure handling, and plugin-centered automation matches your operating model.

Jenkins’ story in this ToolVitals snapshot is not that an old CI server suddenly became new. It is that a mature automation project is still shipping, still hardening, and now adding AI-adjacent help in places where review and retrieval can be measured. That is a better signal than hype.

Sources