Jkit — a small Jenkins CLI for the terminal-driven workflow

Using Jenkins Showing Off
1

Hey all,

I’ve been letting an AI agent (Claude Code, in my case) make non-trivial changes in our repos, and the missing piece was always the same: how does it know whether the change actually built and passed CI? Without that loop, the agent is flying blind — it makes a change, I push, I babysit Jenkins, I paste the failed log back in, it tries again. That’s not an agent, that’s me with extra steps.

So the real ask was: give the agent a clean way to trigger a build, wait for it, fetch the failed stage log, and reason about it — without handing it credentials. Existing options weren’t great for that. jenkins-cli.jar is built for admins, the REST API + curl works but every interaction is five lines of plumbing, and Blue Ocean URLs need parsing. I wanted something an agent could call with one short command and get useful output back.

That turned into jkit (GitHub - ysmaoui/jkit: a cli for interacting with jenkins pipeline jobs and build · GitHub) — a small Go CLI that’s gh for Jenkins. Turns out once you have it, you stop opening the web UI for yourself either.

jkit run my-app --wait --log     # trigger, wait, stream
jkit status my-app               # recent builds
jkit log my-app -f               # tail live build log
jkit diagnose my-app             # summarize the failure
jkit lint                        # validate ./Jenkinsfile

A few things I leaned into because of the agent use case (and that turned out to be nice for humans too):

  • Auth stays out of the agent’s hands — jkit auth login once, token lives in ~/.config/jkit/config.yml, the agent just calls jkit and never sees the credential. No env vars in prompts, no token in tool arguments, no risk of it ending up in a transcript or pasted into a chat.
  • Zero-config — resolves the job from .jkit.yml, then git remote origin, then the directory name. The agent doesn’t need to be told which job to look at.
  • Paste any URL — classic or Blue Ocean. Host, job path, build number all extracted. So when CI posts a link, you (or the agent) can hand it straight back.
  • jkit diagnose URL — one-shot failure summary: failed stage, error excerpts, params, triggering commits. This is the command that closes the feedback loop — most failures are diagnosable from this one output.
  • JSON output everywhere — --json on every command, composes with jq and structured tool calls.
  • Multi-host — --host flag plus aliases in config, for the classic “we have three Jenkinses” setup.

Repo also ships a small Claude Code skill bundle in agents/ — basically a SKILL.md reference, a /jenkins-monitor URL slash command, and a sub-agent that does failure triage. Drop it into ~/.claude/ and the agent knows how to use jkit without you prompting it.

Pre-built binaries for Linux / macOS / Windows on amd64 + arm64 on the releases page. go install github.com/ysmaoui/jkit@latest also works.

It’s early — v0.2.0, expect breaking changes before 1.0. Most useful feedback at this stage: workflows it doesn’t cover, output that’s awkward to parse, anything that breaks on your Jenkins version.

(Note on the name: I originally shipped this as jk but renamed to jkit after publishing — there’s already an avivsinai/jenkins-cli project that ships a jk binary. Same idea, different angle. Worth a look if you want a more admin-leaning Jenkins CLI with broader feature coverage.)

Repo: GitHub - ysmaoui/jkit: a cli for interacting with jenkins pipeline jobs and build · GitHub
Docs: jkit/docs at main · ysmaoui/jkit · GitHub

Curious what people think.

2 Likes
2

Any particular advantage developping your own instead of using Jenkins CLI or the other various existing CLI tools? (Ex from first serach result pages, there must be others as well: GitHub - avivsinai/jenkins-cli: GitHub-style CLI for Jenkins — manage contexts, runs, logs, and admin tasks from your terminal. · GitHub)

1 Like
3

vs. the official Jenkins CLI (jenkins-cli.jar) — different
audience. That one is built for admins (script console, safe
restart, plugin install, credentials). It needs a JVM, auth is
SSH-key or password-file, and there’s no JSON output. For the
“did the build pass, what failed, here’s the log” loop it’s
awkward.

vs. existing CLI tools, including @avivsinai’s jenkins-cli —
this one is a real overlap
What I built is narrower and grew out of a specific problem: I
wanted an AI agent to have a usable CI feedback loop without
handing it credentials. That biased the design toward a few things
I haven’t seen elsewhere (happy to be corrected):

  • jkit diagnose URL — one command, one output: failed stage,
    error excerpts, params, triggering commits. Designed to be the
    single tool call an agent makes after a failure.
  • Zero-config job resolution — .jkit.yml → git remote origin
    → directory name. The agent doesn’t need to be told which job;
    it just runs jkit status from the repo.
  • Paste-any-URL parsing — classic and Blue Ocean URLs, host +
    job path + build number extracted.

the name clash — that’s on me, I didn’t search hard enough
before naming. I’ll either rename the binary or namespace it; sorry
for the noise.

1 Like
4

( renamed to jkit )

One more thing I should have mentioned, since it’s a real
architectural difference rather than a feature comparison.

Jenkins exposes pipeline stage/step data through three plugin
generations:

  1. pipeline-rest-api — /wfapi/**. Older, ubiquitous.
  2. blueocean-rest — /blue/rest/.... Deprecated by the
    Jenkins project but still widely deployed.
  3. pipeline-graph-view v803+ — /stages/tree, /stages/log.
    The maintained replacement for both, actively developed by the
    Jenkins core team.

jkit uses PGV by default (with Blue Ocean as a fallback for
older instances). avivsinai/jenkins-cli uses the first generation
(/wfapi/) per its spec. Neither is wrong — wfapi is more
universally available, PGV needs a newer plugin — but it’s a
genuine difference if you’re choosing between the tools, especially
for nested parallel pipelines (PGV gives explicit PARALLEL_BLOCK
typing instead of having to flatten heuristically) and step-level
logs (PGV’s single /stages/log?nodeId= endpoint accepts both
stage and step IDs, no separate aggregation step).

If your controller is recent enough to have PGV ≥ 803, that’s the
direction Jenkins is heading. If it isn’t, jkit falls back to Blue
Ocean automatically — and --pipeline-source=blueocean pins it
explicitly. Adding a wfapi fallback for instances without either
PGV or Blue Ocean is on the list, would close the portability gap.

1 Like
5

Thanks for your detailled replies :slightly_smiling_face: