fix(kirocrew): pin 0.5.0 and preserve managed restarts - #109
Merged
Conversation
added 3 commits
September 2, 2026 07:08
The kirocrew pack pinned 0.3.0 as its default version. Upstream has since cut 0.4.1, which is the current Latest stable release on kirodotdev/KiroCrew, so new installs were landing several releases behind. Bump the pinned default in both places that carry it, and refresh the user-facing text that names the version: - packs/kirocrew/install.sh: pack_config_get fallback, the --kirocrew-version help default, and the stable-lane compatibility note. - packs/kirocrew/manifest.yaml: the param default and the channel/version mismatch example. The channel/version coupling documented in these strings is unchanged: both values still form cli/<channel>/<version>/cli-manifest.json, so an unmatched pair still 403s. Only the version they name moves. Validation: packs/kirocrew/test.sh 73/73 pass, bash -n clean, git diff --check clean, shellcheck -S warning reports only the two pre-existing SC2034 warnings already present on main.
Review caught that the previous commit's pin of "0.4.1" is not installable.
The pack passes --version straight to the upstream installer, which builds
cli/<channel>/<version>/cli-manifest.json and kirocrew-<version>-py3-none-any.whl
from it. Upstream tags the release v0.4.1 but publishes the CLI artifact as
0.4.1rc1, so the tag and the artifact version are not interchangeable.
Measured against the real CDN the installer uses:
stable/0.4.1 cli-manifest.json -> 403
stable/0.4.1rc1 cli-manifest.json -> 200
stable/0.4.1rc1 wheel -> 200
stable/0.3.0 cli-manifest.json -> 200 (old pin, control)
feed/stable/latest-cli.json independently reports version 0.4.1rc1 with
wheel_url .../cli/stable/0.4.1rc1/kirocrew-0.4.1rc1-py3-none-any.whl, and a
host already running the stable lane reports "kirocrew 0.4.1rc1".
Pinning "0.4.1" would therefore have 403'd every install -- the exact failure
mode this param's own documentation warns about.
Changes:
- Pin 0.4.1rc1 in the install.sh fallback and the manifest default.
- Rewrite the help text and manifest description to say this is the ARTIFACT
version rather than the GitHub tag, and to name feed/stable/latest-cli.json
as the way to confirm a pin before changing it. The prior wording ("cut on
the stable lane only") was also misleading: a v0.4.1-insider.1 prerelease
exists, and Insider carries a distinct version identifier.
- Add a "version pin consistency" test asserting manifest default == code
fallback == help default, so a future bump cannot silently leave one of the
three stale.
Validation: packs/kirocrew/test.sh 75/75 pass (73 before, +2 new). The new
assertion was negative-tested: drifting the manifest default to 9.9.9 in an
isolated copy fails with "pin disagrees: manifest='9.9.9' code='0.4.1rc1'
help='0.4.1rc1'". bash -n clean on both files, shellcheck -S warning clean on
test.sh, and install.sh's warning set is unchanged from origin/main (3 SC2034,
pre-existing).
Pin the stable installer artifact after verifying the feed, manifest, wheel URL, and release asset all publish 0.5.0. Expose LowKey's managed kirocrew-gateway unit through the canonical kirocrew.service alias used by KiroCrew 0.5's service-aware restart command, preserving the externally reachable bind and systemd supervision.
royosherove
changed the title
Member
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
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.
Problem / motivation
The KiroCrew pack on
mainstill defaults to0.3.0, while the current stable release is KiroCrew v0.5.0.LowKey also installs the gateway as
kirocrew-gateway.service, but KiroCrew 0.5's service-awarekirocrew restartonly probes the canonicalkirocrew.servicename. Because it cannot see LowKey's active unit, it falls back to terminating the managed process and launching a detached gateway. That replacement does not inherit LowKey's systemd-onlyKIROCREW_HOST=0.0.0.0/KIROCREW_BIND=0.0.0.0environment, so it is no longer a healthy externally reachable backend for the ALB and CloudFront web path.Why it matters
New LowKey installs should receive the requested stable KiroCrew release, and an operator restart must preserve both systemd supervision and the externally reachable bind. Otherwise a routine
kirocrew restartcan leave the local process running while the web experience returns an upstream error.What changed
0.5.0in the installer fallback, CLI help, and pack manifest.Alias=kirocrew.serviceto the existingkirocrew-gateway.serviceunit's[Install]section.systemctl enable kirocrew-gateway.servicenow exposes the canonical name KiroCrew 0.5 probes.kirocrew restarttherefore invokessystemctl restart kirocrew.service, which restarts the same LowKey-managed,0.0.0.0-bound service instead of spawning a loopback-only process.Artifact verification
Verified independently rather than assuming the GitHub tag equals the installer version:
v0.5.0publisheskirocrew-0.5.0-py3-none-any.whl.feed/stable/latest-cli.jsonreportsversion: 0.5.0and the stable0.5.0wheel URL.cli/stable/0.5.0/cli-manifest.jsonreports the same version and wheel URL, with SHA-25648a722da4a1957b3962e42b675c83c19a4b898bca0d54af81a6305c4dd915d57.54,137,817bytes.Tests
CI=true bash packs/kirocrew/test.sh— 76/76 passed.bash -n packs/kirocrew/install.sh packs/kirocrew/test.sh— passed.0.5.0assertion — passed.git diff --check— passed.origin/main(two pre-existing SC2034 warnings ininstall.sh; no new warnings).systemctl --rootsmoke tests proved the alias is created for both:systemctl enable.Alias=kirocrew.servicefrom an isolated pack copy makes the pack test fail withkirocrew restart would bypass systemd.Manual verification
The live gateway on this development host was not restarted, because doing so would interrupt this active KiroCrew session. The service-name mismatch was reproduced by inspecting KiroCrew 0.5's installed service controller (
kirocrew.service) against LowKey's active unit (kirocrew-gateway.service), and the systemd alias behavior was exercised in isolated roots as described above.No visual delta; screenshots are not applicable.
no linked issue: requested directly as a KiroCrew pack update and restart regression fix.