Skip to content
Exlogare
← Back to all posts
by Exlogare Team CLI Go DevOps Release

Launching `exl` — the Exlogare CLI is now generally available

Our command-line interface for ingesting CI logs and querying AI root-cause analyses is out. One Go binary, GitHub Releases, deb/rpm package assets, and Docker — no runtime dependencies.

exl, the Exlogare command-line interface, is shipping today. It is a single Go binary that wraps the public ingest endpoint and the Read API: drop it into a CI runner, a developer workstation, or a cron job, and you have a complete loop — fail-log in, AI root-cause analysis out — without leaving the terminal.

In one paragraph: exl auth login once, then exl ingest from any post-build step, then exl analyses list --since 24h --json | jq from your shell or your morning-digest cron. The CLI is open source (github.com/exlogare/exlogare-cli), Apache-2.0, with zero runtime dependencies.

Install

The most universal path is to download the archive for your OS/arch from GitHub Releases, extract exl, and put it on your $PATH.

Linux package assets are also attached to each release:

# Debian / Ubuntu
curl -fsSL https://github.com/exlogare/exlogare-cli/releases/latest/download/exlogare-cli_amd64.deb -o exl.deb
sudo dpkg -i exl.deb

# Fedora / RHEL / Alma / Rocky
sudo rpm -i https://github.com/exlogare/exlogare-cli/releases/latest/download/exlogare-cli_amd64.rpm

# Docker
docker run --rm -e EXLOGARE_TOKEN ghcr.io/exlogare/exl:latest analyses list --since 24h

Important: .deb and .rpm are published as files in GitHub Releases today. They are not apt/yum repositories with apt install exlogare-cli or dnf install exlogare-cli yet.

Once installed, run exl auth login and paste a token from Settings -> API tokens. The token goes into your OS-native secret store (libsecret, macOS Keychain, Windows Credential Manager) — never to a config file, never to shell history. In CI, use EXLOGARE_TOKEN.

Pattern 1 — wire it into a standalone CI

Most users come to Exlogare via the GitLab / GitHub / Bitbucket OAuth integrations, but a big chunk of CI pipelines still live on Jenkins, Buildkite, Drone, TeamCity or a homegrown Bash CI. For all of those, the CLI is the simplest hook:

# Buildkite step
make test 2>&1 | tee build.log
[[ ${PIPESTATUS[0]} -ne 0 ]] && exl ingest \
    --provider buildkite \
    --project "$BUILDKITE_PIPELINE_SLUG" \
    --status failed \
    --commit "$BUILDKITE_COMMIT" \
    --branch "$BUILDKITE_BRANCH" \
    --pipeline-url "$BUILDKITE_BUILD_URL" \
    --log-file build.log

Set EXLOGARE_TOKEN once in your runner secrets and the same snippet works on Jenkins (post { failure { sh '...' } }), Drone (when: status: [failure]), TeamCity (buildFinished trigger), and anything that exposes shell. The --provider slug is normalised on the server, so Buildkite, BUILDKITE, or My CI 1.0 (prod) all collapse to a sane id — no regex to memorise.

Pattern 2 — morning digests

Several beta teams have ended up writing tiny scripts on top of the Read API to email yesterday's red builds. With exl and jq, the script is one pipe:

exl analyses list --since 24h --severity high --json \
  | jq -r '.items[] | "[\(.severity)] \(.created_at) \(.project_path) — \(.root_cause)"' \
  | mail -s "Yesterday's CI red runs" oncall@yourco.io

Pagination is cursor-based, so the page boundaries are stable across new inserts (unlike offset/limit). For a simple digest you'll always be inside the first page; if you want to walk an entire window, follow next_cursor until it's empty.

Pattern 3 — Grafana panels via the Read API

If you've already imported our Grafana dashboard, exl is a useful sanity check during onboarding: paste your read-token into exl auth login, then run exl analyses list --severity high --limit 5 to confirm the data is flowing before you wire the dashboard datasource. Same endpoint, friendlier output for humans.

What the CLI is not

A few things we deliberately left out of 0.1.0:

  • No interactive TUI. Subcommands are scriptable; that is the whole point. If you want a UI, the dashboard is the UI.
  • No exl webhook / exl integration commands. OAuth flows belong in the browser. The CLI is for ingest + read.
  • No npm distribution. Wrapping a Go binary in a Node package adds zero value and one supply-chain hop.
  • No config file. Settings come from flags, env vars, or the OS keychain. Secrets stay out of dotfiles by design.

Where to go next

If you find a bug, please file it on the GitHub repository. If you want to ship a feature you'd like to see, PRs are welcome — the codebase is small and idiomatic Go, with cobra for commands and go-keyring for credentials.