[Request]: Add a `container upgrade` command

[Saviollage]

Feature or enhancement request details

Today, upgrading an installed container toolset requires running the update-container.sh shell script that ships in /usr/local/bin. The script works well, but as a separate script it is not discoverable from the CLI itself (container --help gives no hint that an updater exists), it depends on jq-style text processing, and its logic cannot be unit tested.

I would like to contribute a native, top-level container upgrade command that replicates the script's behavior exactly:

container upgrade                 # upgrade to the latest GitHub release
container upgrade -v 0.6.0        # upgrade (or downgrade) to a pinned release tag
container upgrade -f              # force reinstall of the target version

Proposed behavior (strict parity with scripts/update-container.sh):

1. Refuse to run while com.apple.container.* launchd services are running, directing the user to container system stop first (the command does not stop services itself).
2. Resolve the target release via the GitHub releases API (releases/latest, or releases/tags/<tag> with -v).
3. Exit successfully with an "already on version" message when the installed version matches the target, unless -f is passed.
4. Prefer the signed installer package (container-installer-signed.pkg / container-<version>-installer-signed.pkg), falling back to the unsigned package only after interactive confirmation.
5. Download to a temporary directory and install via sudo installer -pkg <pkg> -target / — trust continues to come from macOS Installer/Gatekeeper validating the signed package.

Implementation sketch: a new UpgradeCommand in Sources/ContainerCommands/ following the existing AsyncLoggableCommand pattern, with the release-resolution and asset-selection logic in pure functions covered by unit tests, plus an integration test that verifies the running-service guard. docs/command-reference.md would be updated accordingly.

Explicit non-goals for a first iteration (possible follow-ups): auto-stopping services before upgrade, semver-aware comparison, a --dry-run mode, and a download progress bar.

I have this working locally and can open a PR if the direction sounds good. Happy to adjust scope — including whether update-container.sh should eventually be deprecated in favor of the command, or kept alongside it.

Code of Conduct

• I agree to follow this project's Code of Conduct

[jglogan]

Hi @Saviollage, thank you for the issue and PR. We'd prefer to keep upgrade out of container itself for now.

To upgrade inside container, the tool would need to know how it was installed. Your implementation assumes that the user installed the tool via the package installer from the apple/container release page. What if this is not the case?

[Saviollage]

Fair point @jglogan. I've updated the PR (#1943) so container upgrade first detects how the tool was installed and acts accordingly:

• Installer package — identified by the com.apple.container-installer receipt (the same one scripts/uninstall-container.sh uses); keeps the existing download-and-install flow.
• Homebrew — identified by the running executable resolving into a Homebrew Cellar (which also disambiguates the shared /usr/local prefix on Intel Macs); delegates to brew upgrade container (brew reinstall with --force). --release is rejected here, since the formula only offers its latest version.
• Unknown (e.g. a build from source) — exits with an error pointing the user at manual upgrade options instead of overwriting files it doesn't own.

Totally understand if you'd still prefer to keep upgrade out of container for now, just wanted the PR to handle the installation-method question properly in case it's worth reconsidering.