# Jkit — a small Jenkins CLI for the terminal-driven workflow **URL:** \ **Category:** Showing Off\ **Created:** [May 4, 2026, 12:31pm UTC](https://community.jenkins.io/t/jkit-a-small-jenkins-cli-for-the-terminal-driven-workflow/36859 "2026-05-04T12:31:55Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ysmaoui](https://avatars.discourse-cdn.com/v4/letter/y/d9b06d/32.png) [@ysmaoui](https://community.jenkins.io/u/ysmaoui)\ **Post date:** [May 4, 2026, 12:31pm UTC](https://community.jenkins.io/t/jkit-a-small-jenkins-cli-for-the-terminal-driven-workflow/36859/1 "2026-05-04T12:31:55Z")
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](https://github.com/ysmaoui/jkit)) — a small Go CLI that’s `gh` for Jenkins. Turns out once you have it, you stop opening the web UI for yourself either. ```bash 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](https://github.com/ysmaoui/jkit) Docs: [jkit/docs at main · ysmaoui/jkit · GitHub](https://github.com/ysmaoui/jkit/tree/main/docs) Curious what people think. ---
**Author:** ![lemeurherve](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/lemeurherve/32/17166_2.png) [@lemeurherve](https://community.jenkins.io/u/lemeurherve)\ **Post date:** [May 4, 2026, 12:58pm UTC](https://community.jenkins.io/t/jkit-a-small-jenkins-cli-for-the-terminal-driven-workflow/36859/2 "2026-05-04T12:58:24Z")
Any particular advantage developping your own instead of using [Jenkins CLI](https://www.jenkins.io/doc/book/managing/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](https://github.com/avivsinai/jenkins-cli)) ---
**Author:** ![ysmaoui](https://avatars.discourse-cdn.com/v4/letter/y/d9b06d/32.png) [@ysmaoui](https://community.jenkins.io/u/ysmaoui)\ **Post date:** [May 4, 2026, 1:15pm UTC](https://community.jenkins.io/t/jkit-a-small-jenkins-cli-for-the-terminal-driven-workflow/36859/3 "2026-05-04T13:15:42Z")
**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. ---
**Author:** ![ysmaoui](https://avatars.discourse-cdn.com/v4/letter/y/d9b06d/32.png) [@ysmaoui](https://community.jenkins.io/u/ysmaoui)\ **Post date:** [May 4, 2026, 1:26pm UTC](https://community.jenkins.io/t/jkit-a-small-jenkins-cli-for-the-terminal-driven-workflow/36859/4 "2026-05-04T13:26:42Z")
( 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. ---
**Author:** ![lemeurherve](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/lemeurherve/32/17166_2.png) [@lemeurherve](https://community.jenkins.io/u/lemeurherve)\ **Post date:** [May 4, 2026, 1:58pm UTC](https://community.jenkins.io/t/jkit-a-small-jenkins-cli-for-the-terminal-driven-workflow/36859/5 "2026-05-04T13:58:07Z")
Thanks for your detailled replies 🙂