fix: install both CLI archive namings (kapi_ and 1.2.0's kapi-cli_) + prerelease canary#2
Merged
Merged
Conversation
… prerelease canary The 1.2.0 release packaging (scripts/package-cli.sh in neokapi/neokapi) renamed the CLI archive kapi_<ver>_<os>_<arch>.<ext> → kapi-cli_<ver>_…, mirroring the Homebrew naming. Every 1.2.0 RC already publishes the new name, so the moment 1.2.0 stable ships, this action's download step would 404 for every consumer workflow. Resolve the archive name from checksums.txt — the release's own asset manifest — preferring kapi-cli_ and falling back to kapi_, so both eras install (verified locally against v1.1.0 and v1.2.0-rc9). Also add a daily schedule to the test workflow plus a prerelease canary job that installs the newest vX.Y.Z-* CLI prerelease: release-packaging changes land on RCs first, so this class of breakage now fails here weeks before it can reach a stable release. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01NBoxTTZe69Nyssa6QSMxFK
The plugins input now defaults to 'bowrain' so server-connected projects work out of the box; pass '' to install nothing. Along the way: the documented example ref 'kapi-bowrain' never worked — the registry names the plugin 'bowrain' (kapi plugins install does an exact index lookup; 'kapi-bowrain' errors "not in registry"), verified against the live registry. Plugin install was previously not covered by this repo's CI, so the broken example went unnoticed; with the new default, every test job now exercises it. The install step strips a 'kapi-' prefix so the binary-name spelling installs too. Co-Authored-By: Claude Fable 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01NBoxTTZe69Nyssa6QSMxFK
asgeirf
added a commit
to neokapi/registry
that referenced
this pull request
Jul 16, 2026
The v1.1.0 release ships signed kapi-bowrain windows zips
(kapi-bowrain_1.1.0_windows_{amd64,arm64}.zip + sigstore bundles, same
release.yml@refs/tags/v1.1.0 identity as the registered platforms), but
the registry entry only listed darwin/linux — so `kapi plugins install
bowrain` failed on Windows with "no version ... for platform
windows/amd64". Surfaced by setup-kapi's CI once the action started
installing the plugin by default (neokapi/setup-kapi#2).
sha256 values are from the release's checksums.txt; the cert identity
was read from the actual Fulcio certificate in the windows zip's
sigstore bundle.
Claude-Session: https://claude.ai/code/session_01NBoxTTZe69Nyssa6QSMxFK
Co-authored-by: Claude Fable 5 <[email protected]>
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
1 participant
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.
The break
The 1.2.0 release packaging (
scripts/package-cli.shin neokapi/neokapi) renamed the CLI archivekapi_<ver>_<os>_<arch>.<ext>→kapi-cli_<ver>_…, mirroring the Homebrew naming (the CLI toolchain iskapi-cli). Every 1.2.0 RC already publishes the new name; this action still downloads the old one. The moment v1.2.0 stable ships,setup-kapi@v1404s for every consumer workflow (version: latestresolves to 1.2.0 → asset not found).The fix
download-verify.shnow resolves the archive name fromchecksums.txt— the release's own asset manifest — preferringkapi-cli_and falling back tokapi_, so both eras install:kapi_1.1.0_linux_amd64.tar.gz, checksum OK, extractskapi-cli_1.2.0-rc9_linux_amd64.tar.gz, checksum OK, extractsChecksum verification switches from substring
grepto exactawk '$2 == name'matching against both files' real formats.The canary
test.ymlgains a dailyschedule(the action can break without a commit here — this rename is exactly that class) and a prerelease canary job that installs the newestvX.Y.Z-*CLI prerelease. Packaging changes land on RCs first, so this now fails weeks before the same breakage reaches stable. On this PR, that job exercises the fix against v1.2.0-rc9 directly.After merge
Tag a release so the
v1floating tag moves (release.yml handles it) — consumers pin@v1.🤖 Generated with Claude Code
https://claude.ai/code/session_01NBoxTTZe69Nyssa6QSMxFK