Tell the installer API whether this is a fresh install or an upgrade - #15259
Open
schacon wants to merge 1 commit into
Open
Tell the installer API whether this is a fresh install or an upgrade#15259schacon wants to merge 1 commit into
schacon wants to merge 1 commit into
Conversation
The installer already discovers an existing install, but only after the binary has been downloaded -- by which point the API has answered, so the server can never distinguish the two. Every request to /installers/info looks identical whether someone is installing for the first time or re-running the script to update. Detecting it before the request makes it countable: ?from=none for a fresh install, ?from=<version> for an upgrade, ?from=unknown when a binary is present but its version cannot be parsed. Only a version number is sent -- no path, hostname, or anything about the machine -- and it is parsed down to digits and dots, so whatever the local binary prints cannot inject into the URL. The match is anchored at the start of the string because a leading .* matches greedily and would leave only the final digit behind.
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the scripts/install.sh bootstrapper to report whether it’s running as a first-time install or as an upgrade, enabling the installer API endpoint to distinguish and count these cases before the binary download occurs.
Changes:
- Detects an existing
butinstallation and derives a safefromvalue (none,<version>, orunknown). - Appends
?from=$EXISTING_VERSIONto the/installers/info/...API request to pass that context to the server.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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.
The installer already discovers an existing install, but only after the binary
has been downloaded -- by which point the API has answered, so the server can
never distinguish the two. Every request to /installers/info looks identical
whether someone is installing for the first time or re-running the script to
update.
Detecting it before the request makes it countable: ?from=none for a fresh
install, ?from= for an upgrade, ?from=unknown when a binary is present
but its version cannot be parsed.
Only a version number is sent -- no path, hostname, or anything about the
machine -- and it is parsed down to digits and dots, so whatever the local
binary prints cannot inject into the URL. The match is anchored at the start of
the string because a leading .* matches greedily and would leave only the final
digit behind.