Resolve latest to the CLI, and cache plugins where kapi actually puts them#1
Merged
Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Audit of setup-kapi turned up two silent bugs. Both are live on
@v1today.1.
version: latestis broken — it resolves to a pluginThe script asked GitHub for
releases/latest. Butneokapi/neokapipublishes 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:So
latestresolvedVERSION=check-v0.1.0, then tried to downloadkapi_check-v0.1.0_linux_amd64.tar.gzfrom tagvcheck-v0.1.0→ 404. Anyone using the default (orversion: latest) is broken until a CLI release happens to be the newest thing published.latestnow resolves the newest stable CLI release itself — tags of the exact shapevX.Y.Z, excluding drafts, prereleases (v1.2.0-rc9), and plugin/app prefixes (check-v*,asr-v*,bowrain-v*). Verified against the live API:releases/latest)check-v0.1.0→ 4041.1.0✅v1.1.0/1.0.0With that fixed, the default
versionbecomeslatestrather than a pinned, now-stale1.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/pluginson a runner, whereXDG_DATA_HOMEis 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-hitwas nevertrue, 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_arm64only — there is nodarwin_amd64archive. An x64 macOS runner used to get a 404 on a release asset.platform.shnow says plainly what happened and points at an arm64 runner.README
kapi sync(retired —upis the convergence verb).latestcan't use GitHub's latest-release flag, so nobody "simplifies" it back.Verification
All three scripts
shellcheck-clean,action.ymlparses, and the resolver was run against the live GitHub API (table above). The repo's owntest.ymlinstalls on ubuntu/macos/windows on every PR — this exercises the fixedlatestpath by default.