feat: version check

[infiniteregrets]

Important

Add version check command to CLI for checking the latest release from GitHub.

• Behavior:
  • Adds VersionCheck command to Commands enum in main.rs to check for the latest version.
  • Uses check_for_updates() in updates.rs to fetch the latest release from GitHub.
  • If a new version is available, prints the latest version and update instructions; otherwise, confirms the software is up-to-date.
• Dependencies:
  • Adds reqwest dependency in Cargo.toml for HTTP requests.
• Misc:
  • Updates Cargo.lock with new dependencies and versions.

^{This description was created by for 1b8a3e4. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 1b8a3e4 in 1 minute and 59 seconds

More details

• Looked at 1039 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 5 drafted comments based on config settings.

1. src/updates.rs:30

• Draft comment:
  Consider using a dedicated semver parser instead of string comparison for version numbers. For example, comparing '0.10.0' with '0.8.4' lexically may yield incorrect results.
• Reason this comment was not posted:
  Marked as duplicate.

2. src/updates.rs:28

• Draft comment:
  Consider checking the HTTP response status explicitly before attempting to deserialize JSON. This could help in diagnostics if GitHub returns an error response.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
  The code already has reasonable error handling through ok()? pattern. Adding explicit status checking would be redundant since reqwest handles this. The function returns Option and gracefully handles all errors by returning None. For a simple update checker, this level of error handling is appropriate - users don't need detailed error diagnostics.
  Maybe detailed error diagnostics would help users understand why update checks fail. The current code silently fails with None for any error.
  For an update checker that runs in the background, silent failure is actually preferable - users don't need to see diagnostic messages for temporary network issues or GitHub API problems.
  The comment should be deleted. The existing error handling is appropriate for this use case, and adding explicit status checking would be unnecessary complexity.

3. src/main.rs:106

• Draft comment:
  In the documentation for the 'Ls' subcommand, please change 'upto a maximum of 1000' to 'up to a maximum of 1000' for clarity.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. src/main.rs:122

• Draft comment:
  Please update 'upto a maximum of 1000' to 'up to a maximum of 1000' in the 'ListBasins' subcommand documentation.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

5. src/main.rs:256

• Draft comment:
  In the 'Fence' subcommand documentation, please change 'It may be upto 16 bytes' to 'It may be up to 16 bytes' for proper spacing.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_pwps4bngM3o6iCqB

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

Consider using a proper semantic versioning comparison instead of string comparison (lines 30-37). Lexicographical comparison can misorder versions (e.g., "10.0" vs "9.9"). Using the semver crate would be more robust.