Add update subcommand to pull the latest CLI release version locally

[twinfees]

Target component

• CLI
• SDK
• Something else
• Not sure

Overview

Looking at the list of command options with the oxide CLI, it doesn't look like there's a way to update in-place:

Commands:
  experimental
  certificate
  disk
  floating-ip
  group
  image
  instance
  project
  current-user
  ping          Ping API
  policy
  snapshot
  system
  silo
  ip-pool
  user
  utilization   Fetch resource utilization for user's current silo
  vpc
  auth          Login, logout, and get the status of your authentication.
  api           Makes an authenticated HTTP request to the Oxide API and prints the response.
  docs          Generate CLI docs in JSON format
  version       Prints version information about the CLI.
  completion    Generate shell completion scripts for Oxide CLI commands.
  help          Print this message or the help of the given subcommand(s)

And no subcommand option to do so either with the version command:

izzyfee@Elizabeths-MBP /opt/oxide-cli-x86_64-apple-darwin$ oxide version --help                                                                                                                                                                           
Prints version information about the CLI.

Usage: oxide version

Options:
  -h, --help  Print help

Implementation details

While it's easy enough to grab the latest release from https://github.com/oxidecomputer/oxide.rs/releases, it might be nice to be able to do something like oxide version update --latest or oxide version list to see a list of versions available wherein one could then specify the version they want to go to (including downgrading if needed), e.g. oxide version update --target <version_num>.

Anything else you would like to add?

No response

[ahl]

I like this idea. Would you imagine this just replacing the binary wherever it happens to be installed? I would suggest we do something like this:

• oxide version update -- queries the API server for its current version (somehow), figures out the latest binary that's compatible with that version, prompts the user (Are you sure? [Y/n]), downloads the binary, replaces at the current location.
• oxide version update --yes -- Same as above, but without the confirmation
• oxide version update --no-profile [--yes] -- Doesn't query the API server, just gets the latest release binary which may or may not be compatible with what's running on the server.
• oxide version list -- List available CLI versions--this might be a long list, maybe we want to show the most recent 5 or so?
• oxide version update --target <version_num> [--yes] -- Update to the specific version number--do we want to check for compatibility with the API server?

How would we / do we want to handle the situation where a customer has 2 racks / AZs that might potentially be running different versions of the Oxide software (i.e. incompatible / non-matching API versions)? This situation isn't immediate, but it's probably not too far into the future. Perhaps we can ignore that for the moment and anticipate greater API / CLI stability by the time that becomes a significant issue.

[david-crespo]

I think we should punt given that it's not happening any time soon, and in a dire situation the customer can deal with it by having two different binaries around. I don't see us getting much more sophisticated than that any time soon even in the best case.

---

And now to bikeshed on command names: I've seen a convention oxide self ... that I kind of like. Nextest does this:

$ cargo nextest self update -h
Download and install updates to nextest

Usage: cargo nextest self update [OPTIONS]

Options:
      --version <VERSION>            Version or version range to download [default: latest]
  -n, --check                        Check for updates rather than downloading them
  -v, --verbose                      Verbose output [env: NEXTEST_VERBOSE=]
      --color <WHEN>                 Produce color output: auto, always, never [env: CARGO_TERM_COLOR=] [default: auto]
  -y, --yes                          Do not prompt for confirmation
  -f, --force                        Force downgrades and reinstalls
      --releases-url <RELEASES_URL>  URL or path to fetch releases.json from
  -h, --help                         Print help (see more with '--help')

Manifest options:
      --manifest-path <PATH>  Path to Cargo.toml

Config options:
      --config-file <PATH>
          Config file [default: workspace-root/.config/nextest.toml]
      --tool-config-file <TOOL:ABS_PATH>
          Tool-specific config files
      --override-version-check
          Override checks for the minimum version defined in nextest's config

[citrus-it]

To cater for anyone that happens to deliver the CLI as an OS package with whatever package manager, should we provide an option for them to compile this out to prevent users shooting themselves in the foot?

[ahl]

Great idea. Maybe a compilation option to display a message like 'use brew update, idiot!'

[wfchandler]

On macOS we'll need to notarize our binaries to avoid having the user needing to manually trust the binary after each update: #280