Repository navigation
feat(release): distribution channels — native bundles, npm, Homebrew, Docker CLI - #10
Merged
Merged
Conversation
… Docker CLI 'Add all the support': the direct CLI and server now reach users through every standard channel, all wired into the release workflow. - native bundles: a bundles matrix job (ubuntu/macos/windows) runs jpackage app-images with a bundled JRE — kview-<v>-linux-x64.tar.gz (+ a .deb), kview-<v>-macos-aarch64.tar.gz, kview-<v>-windows-x64.zip — each containing the server launcher and a kview direct-CLI wrapper, so no Java install is needed. Windows launcher validated locally: bundled runtime runs 'kview.exe --cli --version' with no system Java. - npm: the 'kview' package (bin/kview dispatcher: direct mode via KVIEW_JAR or a local kview-*.jar, thin client otherwise; bin/kview-mcp for 'npx kview-mcp'), published with the release version when NPM_TOKEN is set. - Homebrew: packaging/homebrew/kview.rb.tmpl rendered and pushed to the tap on release when HOMEBREW_TAP_TOKEN is set (formula installs both the direct-CLI 'kview' and 'kview-server' from the bundle). - release.yml restructured: build job uploads the tested jar as an artifact (bundles rebuild-free consume it), a publish job attaches bundles to the GitHub release and handles npm/Homebrew (steps skip gracefully while their secrets are unconfigured). - docs: docs/RELEASING.md (per-channel checklist incl. the manual SDKMAN submission) and a README install table (jar / bundles / npm / Docker / Homebrew; Docker also passes the CLI through: 'docker run --rm image --cli topics ...'). - verified locally: npm pack contents + both dispatcher modes + npm MCP bin (19 tools); jpackage app-image on Windows with the bundled runtime; workflow YAML structure; full suite 66/66.
…SING.md from the README docs/RELEASE-PLAN.md is the historical v1.0.0 runbook (its facts are stale: Boot 3.3.4, 30/30 tests, pre-license) — banner it as an archive and point maintainers at docs/RELEASING.md, which is the current release checklist. README Contributing section now links it too.
The image was only on ghcr.io. When the repo secrets DOCKERHUB_USERNAME, DOCKERHUB_TOKEN and DOCKERHUB_REPOSITORY are configured, the release now copies the already-published multi-arch manifest from GHCR to Docker Hub with 'docker buildx imagetools create' (same digests, both :version and :latest, no rebuild) and skips gracefully while the secrets are absent — the same pattern as npm and Homebrew. RELEASING.md documents the three secrets; the README Docker row mentions the mirror.
Consolidated draft covering the ten stacked PRs: security & safety (auth roles, AI/MCP pack), new features (search, replay, protobuf, metrics, direct CLI), distribution channels (bundles/npm/Docker Hub/Homebrew/SDKMAN), platform (Boot 3.5.16), the 18 resolved verified issues, the quality statement (66/66 across 18 classes, Linux+Windows matrix), upgrading notes, and the remaining roadmap (registry browser, live-registry protobuf verification, packaging secrets).
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.
"Add all the support": wires every standard distribution channel around the direct CLI and server from #9. Stacked on #9 (introduces the
--climode the wrappers call) — merge #1 → … → #9 → this.Channels
kview-<v>-linux-x64.tar.gz(+.deb),kview-<v>-macos-aarch64.tar.gz,kview-<v>-windows-x64.zip— server launcher and akviewdirect-CLI wrapperkviewpackage:bin/kviewdispatcher (direct mode viaKVIEW_JARor a localkview-*.jar; thin client otherwise) +npx kview-mcp(19 tools)brew install kview→kviewCLI +kview-server, both on the bundled JRE)HOMEBREW_TAP_TOKENdocker run --rm ghcr.io/ritikbansod/kview --cli topics ...passes the CLI through the existing entrypointdocs/RELEASING.md(Linux bundle URL per release)Workflow
release.ymlrestructured into three jobs: build (tested jar → artifact + GitHub Release + Docker), bundles (per-OS jpackage matrix consuming the artifact — no rebuild divergence), publish (attaches bundles to the release; npm publish and Homebrew tap update activate only when their secretsNPM_TOKEN/HOMEBREW_TAP_TOKENare configured, and skip gracefully otherwise).docs/RELEASING.mddocuments the per-channel setup and the release checklist.Verified locally (not just designed)
kview.exe --cli --version→kview 1.0.0. (This also caught the real Windows layout: the launcher sits at the app root, notbin/— the workflow wrapper is written against the verified layout. Linux usesbin/kview, macOSkview.app/Contents/MacOS/kview.)npm packcontents checked (7 files); both dispatcher modes exercised — thin client--versionand direct mode throughKVIEW_JAR(which routes into the jar'sCliMain --version);kview-mcpbin serves 19 tools over stdio.Not verifiable from here
-rc.1tag to watch it end to end. macOS bundles are unsigned (Gatekeeperxattr -crnoted in docs).