Skip to content

Resolve latest to the CLI, and cache plugins where kapi actually puts them#1

Merged
asgeirf merged 2 commits into
mainfrom
fix/latest-and-plugin-cache
Jul 13, 2026
Merged

Resolve latest to the CLI, and cache plugins where kapi actually puts them#1
asgeirf merged 2 commits into
mainfrom
fix/latest-and-plugin-cache

Conversation

@asgeirf

@asgeirf asgeirf commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Audit of setup-kapi turned up two silent bugs. Both are live on @v1 today.

1. version: latest is broken — it resolves to a plugin

The script asked GitHub for releases/latest. But neokapi/neokapi publishes the CLI, the desktop apps, the bowrain server, and every plugin from one repo, and GitHub's "latest" flag lands on whichever was published most recently. Right now that's a plugin:

$ gh api repos/neokapi/neokapi/releases/latest --jq .tag_name
check-v0.1.0

So latest resolved VERSION=check-v0.1.0, then tried to download kapi_check-v0.1.0_linux_amd64.tar.gz from tag vcheck-v0.1.0 → 404. Anyone using the default (or version: latest) is broken until a CLI release happens to be the newest thing published.

latest now resolves the newest stable CLI release itself — tags of the exact shape vX.Y.Z, excluding drafts, prereleases (v1.2.0-rc9), and plugin/app prefixes (check-v*, asr-v*, bowrain-v*). Verified against the live API:

resolver result
old (releases/latest) check-v0.1.0 → 404
new 1.1.0
pinned v1.1.0 / 1.0.0 passes through unchanged ✅

With that fixed, the default version becomes latest rather than a pinned, now-stale 1.0.0 — which is what the README already claimed.

2. The plugin cache pointed at the wrong directory

kapi installs plugins under $XDG_DATA_HOME/kapi/plugins — i.e. ~/.local/share/kapi/plugins on a runner, where XDG_DATA_HOME is unset (cli/plugincmds.go: "…installs to $XDG_DATA_HOME/kapi/plugins/<name>/"). The cache saved ~/.config/kapi/plugins: the config dir, which kapi never writes a plugin to.

So the plugin cache stored nothing, cache-hit was never true, and every run re-downloaded every plugin. Now cached at the real path.

3. Intel macOS fails late instead of early

The CLI ships darwin_arm64 only — there is no darwin_amd64 archive. An x64 macOS runner used to get a 404 on a release asset. platform.sh now says plainly what happened and points at an arm64 runner.

README

  • Drops kapi sync (retired — up is the convergence verb).
  • Corrects the platform table: macOS is arm64-only.
  • Explains why latest can't use GitHub's latest-release flag, so nobody "simplifies" it back.

Verification

All three scripts shellcheck-clean, action.yml parses, and the resolver was run against the live GitHub API (table above). The repo's own test.yml installs on ubuntu/macos/windows on every PR — this exercises the fixed latest path by default.

asgeirf added 2 commits July 13, 2026 10:43
…ly puts them

Two bugs, both silent.

`version: latest` was broken. It asked GitHub for `releases/latest`, but one
repository publishes the CLI, the desktop apps, the bowrain server, AND every
plugin — so that flag lands on whichever was published last. Today that is a
plugin: `check-v0.1.0`. The Action resolved VERSION=check-v0.1.0, then tried to
download `kapi_check-v0.1.0_linux_amd64.tar.gz` from tag `vcheck-v0.1.0` and
404'd. `latest` now scans releases for the newest stable CLI tag (exactly
vX.Y.Z, no draft, no prerelease, no plugin/app prefix) — which resolves to 1.1.0
rather than check-v0.1.0. With that fixed, the default version becomes `latest`
instead of a pinned, now-stale 1.0.0; the README already claimed `latest`.

The plugin cache pointed at the wrong directory. kapi installs plugins under
$XDG_DATA_HOME/kapi/plugins (~/.local/share/kapi/plugins on a runner, where
XDG_DATA_HOME is unset), but the cache saved ~/.config/kapi/plugins — the CONFIG
dir, which kapi never writes a plugin to. So the cache stored nothing, cache-hit
was never true, and every run re-downloaded every plugin.

Also: the CLI publishes no Intel-macOS archive, so an x64 macOS runner used to
fail with a 404 on an asset that does not exist. platform.sh now says so.

README: drop `kapi sync` (retired — `up` is the convergence verb), correct the
platform table (macOS is arm64-only), and explain why `latest` cannot use
GitHub's latest-release flag.
The pinned-version job computed its version with the same `releases/latest`
call the action had, and hit the same bug: it resolved "check-v0.1.0" (a plugin
release) and then asked the action to install a kapi CLI of that version. It now
calls the action's own resolver, so CI exercises the shipped logic instead of a
second, divergent copy of it.
@asgeirf
asgeirf merged commit 76ab0b4 into main Jul 13, 2026
9 checks passed
@asgeirf
asgeirf deleted the fix/latest-and-plugin-cache branch July 13, 2026 02:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant