Recommend upgrading the CLI when a newer release is available#5482
Closed
shreyas-goenka wants to merge 4 commits into
Closed
Recommend upgrading the CLI when a newer release is available#5482shreyas-goenka wants to merge 4 commits into
shreyas-goenka wants to merge 4 commits into
Conversation
Print a short advisory on stderr when the installed CLI is older than the latest GitHub release, modeled on `gh`'s update notifier. The check never adds latency to a command: every run reads the latest known version from a local cache (~/.databricks/cli-version-check.json). The GitHub API is only contacted by a background goroutine, and only when the cache is older than 24h; the notice is always rendered from the cache. The cache write is atomic, so a short-lived process can't corrupt it. The notice is suppressed unless it is actionable and wanted: only for released builds, interactive text output (TTY), and not on Databricks Runtime or in CI. Co-authored-by: Isaac
Co-authored-by: Isaac
shreyas-goenka
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
shreyas-goenka
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Collaborator
|
Commit: 0af75c1
24 interesting tests: 15 SKIP, 7 KNOWN, 2 flaky
Top 29 slowest tests (at least 2 minutes):
|
- Append an OS/install-method aware upgrade command to the notice: `brew upgrade databricks` for Homebrew installs (detected from the binary location), `winget upgrade Databricks.DatabricksCLI` on Windows, otherwise the install script. - Make the once-per-day cache TTL on the background refresh explicit. - A failed refresh (e.g. no network) stays silent; it is not surfaced. - Fix CI lint: use errors.Is(fs.ErrNotExist) / assert.ErrorIs in tests. Co-authored-by: Isaac
Co-authored-by: Isaac
Contributor
Author
|
Closing because Simon has the same PR up: #5470 |
simonfaltum
added a commit
that referenced
this pull request
Jun 9, 2026
Adopts the cleaner structure from the alternative PR #5482: the suppression policy is now a pure shouldNotify(notifyConditions) function (table-tested with no mocks), condition-gathering is split from the policy, and rendering (noticeMessage) is split from gating so both are unit-testable. Also suppresses on the Databricks Runtime and includes the release-notes URL in the message. Keeps the single-flight lock, opt-out env, libs/cache, and once-per-day display throttle from this PR. Co-authored-by: Isaac
5 tasks
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
2 participants
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.
Why
Users on outdated CLI versions hit bugs that are already fixed and miss new features, with no signal that an upgrade exists. This adds a non-intrusive "a newer release is available" advisory, modeled on the GitHub CLI (
gh) — same language, same distribution channel (GitHub releases).The latency problem, and how this avoids it
The hard requirement is that the check must never add latency to a command. So:
~/.databricks/cli-version-check.json.api.github.com/repos/databricks/cli/releases/latest. The command never blocks on it.What the user sees
Printed to stderr, after a successful command, in yellow, with an install-method-aware upgrade command:
The upgrade command adapts to how the CLI was installed (all per the install docs):
Cellar/):brew upgrade databrickswinget upgrade Databricks.DatabricksCLIcurl -fsSL https://raw.githubusercontent.com/databricks/setup-cli/main/install.sh | shIt is suppressed unless it's actionable and wanted: released builds only (dev/snapshot builds skip entirely — no cache, no network), interactive text output (TTY), not on Databricks Runtime, not in CI, not
--output json.Structure
libs/upgradecheck/— cache read/write, GitHub fetch, version comparison (golang.org/x/mod/semver, already a dependency). Network base URL is context-overridable for tests.cmd/root/upgrade_notice.go— the cobra glue: a pureshouldNotifypolicy + message/upgrade-command builders, wired intoPersistentPreRunE(background refresh) andExecute(print on success).Testing
Unit tests cover the cache lifecycle (fetch → cache → outdated) against an
httptestserver, the 24h staleness throttle, corrupt-cache self-healing, server-failure handling, the release-version gate, the message/upgrade-command builders, and every suppression condition.Manually verified end-to-end with a release-tagged local build (
-X ...build.buildVersion=0.200.0) run under a pseudo-terminal: the recommendation renders on stderr; the Homebrew path showsbrew upgrade databricks;--output json,CI=1, and non-TTY all suppress it; and a live fetch againstapi.github.comreturns the real latest release.This pull request and its description were written by Isaac.