fix(update): clearer error on unsupported release platform (android/termux) - #603
Conversation
…ermux) zero update/upgrade fails on Android/Termux because GOOS "android" has no published release archive. Replace the generic "unsupported release platform: android" error with a clear, actionable message explaining that no release builds are published for the platform, listing the supported platforms, and suggesting a rebuild from source. The command still fails gracefully (clean stderr message, exit 1, no panic/stack trace) rather than crashing. Fixes Gitlawb#598
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughBoth release platform helpers now return more specific errors for unsupported GOOS values, replacing the prior generic message and clarifying that published release artifacts are unavailable on those platforms. ChangesError message update
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR improves the UX of zero update / zero upgrade on unsupported platforms (notably Android/Termux) by replacing the generic “unsupported release platform” error with a clearer, actionable message explaining that official release archives are only published for linux/macos/windows.
Changes:
- Update
releasePlatformto return an explicit, user-actionable error message on unsupportedGOOSvalues (e.g.,android). - Add inline rationale comments documenting why the updater fails loudly on unsupported platforms.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
internal/update/update.go (2)
364-371: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueCondense the comment block.
Eight lines of comments for a single
returnstatement is excessive and will become stale baggage. The core rationale fits in 2–3 lines.♻️ Suggested condensation
default: - // No prebuilt release archives are published for this GOOS (e.g. a - // binary built natively on Android/Termux reports GOOS "android"). - // Fail loudly rather than silently no-op'ing so users don't mistake - // a skipped check for "you're already up to date" — `zero update - // --check` is documented as read-only, but "safe" doesn't mean - // "silently wrong". Building/installing zero on such a platform - // falls outside the release matrix, so `zero update`/`zero upgrade` - // can't check or install; rebuild from source instead. + // No prebuilt release archives exist for this GOOS (e.g. Android/Termux). + // Fail loudly so users don't mistake a skipped check for "up to date"; + // rebuild from source instead. return "", fmt.Errorf("zero does not publish release builds for platform %q (supported: linux, macos, windows) — update/upgrade checks aren't available; rebuild from source instead", goos)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/update/update.go` around lines 364 - 371, Condense the explanatory comment in the update path so it stays maintainable: the block near the GOOS release-matrix check in update.go is too verbose for the single early return it documents. Shorten the comment around the logic in the update/upgrade flow to 2–3 lines while preserving the key point that unsupported platforms like android/Termux should fail loudly rather than silently no-op, and keep the rationale attached to the same return guard.
372-372: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUse the same unsupported-platform message in
internal/release/release.gotoo.ReleasePlatformstill returnsunsupported release platform: %s, so the update and release flows give different guidance for the same case.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/update/update.go` at line 372, The unsupported-platform error message is inconsistent between the update and release flows; `ReleasePlatform` in `internal/release/release.go` still uses the older generic wording. Update that path to use the same detailed unsupported-platform message as the update check (the one tied to `goos` and supported platforms), so both `ReleasePlatform` and the update/upgrade logic return identical guidance for the same case.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@internal/update/update.go`:
- Around line 364-372: The unsupported-platform path in update handling still
returns an error from the release-archive check, which makes zero update --check
exit non-zero instead of skipping gracefully. Update the logic around the
platform validation in internal/update/update.go, especially the helper that
reports unsupported GOOS values and the caller that propagates it, so --check
can return a no-op/informational result while zero update and zero upgrade still
fail only when an actual install is requested. Use the existing update/check
flow and symbols like zero update, zero upgrade, and the GOOS validation branch
to separate read-only checks from install-capable operations.
- Line 372: The CLI error message in the update path uses a Unicode em dash,
which can display incorrectly in some terminals. Update the fmt.Errorf string in
the update/upgrade check logic to use plain ASCII punctuation such as “;” or
“--” instead of “—”, keeping the rest of the message unchanged. Locate the
message in the release-build/platform check near the update code path and
replace the non-ASCII separator there.
---
Nitpick comments:
In `@internal/update/update.go`:
- Around line 364-371: Condense the explanatory comment in the update path so it
stays maintainable: the block near the GOOS release-matrix check in update.go is
too verbose for the single early return it documents. Shorten the comment around
the logic in the update/upgrade flow to 2–3 lines while preserving the key point
that unsupported platforms like android/Termux should fail loudly rather than
silently no-op, and keep the rationale attached to the same return guard.
- Line 372: The unsupported-platform error message is inconsistent between the
update and release flows; `ReleasePlatform` in `internal/release/release.go`
still uses the older generic wording. Update that path to use the same detailed
unsupported-platform message as the update check (the one tied to `goos` and
supported platforms), so both `ReleasePlatform` and the update/upgrade logic
return identical guidance for the same case.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b09fd793-1e62-420d-bee7-dce38b3e44d8
📒 Files selected for processing (1)
internal/update/update.go
- Condense the explanatory comment for the unsupported GOOS branch. - Replace the Unicode em dash with plain ASCII punctuation. - Align internal/release.ReleasePlatform's error message with the updater's so both flows give identical guidance.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
internal/release/release.go (1)
319-319: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider deduplicating the error message string.
The error message at line 319 is now character-for-character identical to the one in
internal/update/update.go'sreleasePlatform(). Both the switch/case logic and the error string are duplicated across the two packages. If one message is updated in the future, the other can silently drift, re-introducing the inconsistency this PR just fixed.Consider extracting the error message into a shared constant (e.g., in
internal/releaseand imported byinternal/update), or havinginternal/update.releasePlatformdelegate tointernal/release.ReleasePlatformdirectly to eliminate the duplicated function entirely.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/release/release.go` at line 319, The platform rejection message and `releasePlatform` logic are duplicated between `internal/release.ReleasePlatform` and `internal/update.releasePlatform`, so refactor to keep a single source of truth. Either extract the shared error string into a reusable constant/helper in `internal/release` that `internal/update` imports, or make `internal/update.releasePlatform` delegate directly to `internal/release.ReleasePlatform` so the identical message cannot drift.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@internal/release/release.go`:
- Line 319: The platform rejection message and `releasePlatform` logic are
duplicated between `internal/release.ReleasePlatform` and
`internal/update.releasePlatform`, so refactor to keep a single source of truth.
Either extract the shared error string into a reusable constant/helper in
`internal/release` that `internal/update` imports, or make
`internal/update.releasePlatform` delegate directly to
`internal/release.ReleasePlatform` so the identical message cannot drift.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 9b88e112-dacb-4109-817e-35a1e2b456d5
📒 Files selected for processing (2)
internal/release/release.gointernal/update/update.go
🚧 Files skipped from review as they are similar to previous changes (1)
- internal/update/update.go
|
The code change is a real UX win. The wording needs a tweak though. "no published release for android (supported: linux, macos, windows). Rebuild from source instead" reads as if Termux isn't a supported platform. It is, just not as a self-updating release asset. PR #509, PR #455, PR #573, and the dictation recorder's PlatformTermux path are all in main. Termux runs Zero fine. A user reading the new message would reasonably conclude "this doesn't run here," which is wrong. The actual distinction is "no release asset for this GOOS," not "platform unsupported." And the upgrade path shouldn't be "rebuild from source." That's hostile to a phone user without a Go toolchain. The right path is the npm wrapper (PR #455), which is the documented Termux install: Suggested wording: The parenthetical lists release platforms, not "supported platforms." And Separate follow-up: the release-artifacts.yml matrix (line 26-31) doesn't include android-arm64. Adding it (cross-compile with GOOS=android, an Android-shaped install script, a smoke test on actual Termux) would make |
… assets Address review feedback: the previous message implied Android/Termux was an unsupported platform and told users to rebuild from source. Termux runs zero fine via the npm wrapper; it just has no self-updating release archive. Point users at 'npm update -g @gitlawb/zero', the documented Termux install/upgrade path, instead.
Summary
Fixes #598.
zero update/zero upgradeon Android/Termux failed with the opaque errorunsupported release platform: android, including for--check, which is documented as a safe, read-only operation.Change
releasePlatformininternal/update/update.gonow returns a clear, actionable error when the running GOOS has no published release archive: it names the platform, lists the supported platforms (linux, macos, windows), and tells the user to rebuild from source. The command still fails (exit 1) rather than silently reporting "up to date," but does so gracefully — a clean stderr message via the existingwriteAppErrorpath, no panic or stack trace.Before:
After:
Testing
go build ./...go test ./internal/update/... ./internal/cli/...Summary by CodeRabbit