databricks-cli: build Replit fork from source, skip tests

[luketchang]

Why

We ended up temporarily forking databricks CLI to unblock and speed up process of fixing some issues. Need to point to our fork replit/databricks-cli.

What changed

pkgs/modules/databricks-cli/default.nix:

• Bumps version from 0.286.0 to 0.299.0-replit.1 and points src at replit/databricks-cli at that tag (upstream v0.299.0 + the squashed sync: add --concurrency and --retry-timeout flags PR Versioning poc #1). Updates hash and vendorHash accordingly.
• Replaces the 13-entry checkFlags skip list (and its supporting nativeCheckInputs / preCheck plumbing) with doCheck = false. Bumping to v0.299.0 surfaced a new offender (TestClearWorkspaceClient hangs on workspace-client DNS resolution and times out at 10 minutes); rather than play whack-a-mole with new entries on every upstream rebase, we skip the whole checkPhase and trust upstream CI. Same pattern that pkgs/modules/python/uv and the docker stack (runc, containerd, buildkit, moby) already use in this repo.
• Updates meta.homepage, meta.changelog, and the description to point at the fork.

NOTE: we skip tests here because the new databricks version introduces a lot of tests that require network calls which cause DNS resolution to hang. This is not ideal but skipping tests in interest of time for now. We do not expect to maintain our own fork long-term, this is a bandaid.

Test plan

$ nix build .#'"databricks-cli"'
$ /nix/store/.../databricks-cli-0.299.0-replit.1/bin/databricks --version
Databricks CLI v0.299.0-replit.1

$ /nix/store/.../bin/databricks sync --help | grep -E 'concurrency|retry-timeout'
      --concurrency int          maximum number of concurrent in-flight requests during sync (default 5)
      --retry-timeout duration   per-call deadline for retrying transient gateway errors (HTTP 502/503/504) (default 30s)

$ nix fmt -- --check .
0 / 82 would have been reformatted

Rollout

• This is fully backward and forward compatible — same module id, same binary name, same replit.packages shape; consumers see only the bumped displayVersion and the new flags.

Future maintenance

Each rebase of the fork's main onto a newer upstream tag → retag vX.Y.Z-replit.<n> on replit/databricks-cli → bump version + hash + vendorHash in this file. The first build after a bump will fail twice with hash mismatches (telling you the new hash and vendorHash); paste them in and rebuild.

Long-term fix is upstreaming --concurrency to databricks/cli so the fork goes away.

Context

Slack thread: https://replit.slack.com/archives/C0A2Z9042FR/p1778082184841149

Fork tag: https://github.com/replit/databricks-cli/releases/tag/v0.299.0-replit.1

~ written by Zerg 👾 (hungry-lurker-7ee9)

[luketchang]

@replit/micromanager approve changing to forked databricks CLI, temporary setup until we get what we need upstreamed