feat(cube-cli): add data-model enable-branch / disable-branch commands

[paveltiunov]

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

Description of Changes Made

Exposes the per-branch staging-environment toggle (Settings → Staging Environments in the UI) through the CLI, so keeping a shared branch's staging environment always active — rather than only while someone views the branch — can be scripted from CI:

cube data-model enable-branch  DEPLOYMENT_ID BRANCH
cube data-model disable-branch DEPLOYMENT_ID BRANCH

Both call PUT /build/api/v1/deployments/{id}/branches/staging-environment with { branchName, enabled }, mirroring how embed enable-dashboard / disable-dashboard drive their boolean endpoint. The endpoint is added in cubedevinc/cubejs-enterprise#13535, so these commands need a tenant running that build.

data-model branches now reports the state as an ENABLED column. Its previous DEFAULT / CURRENT columns read isDefault / isCurrent, which the branches endpoint does not return, so they always rendered empty — they are replaced with PARENT and ENABLED, which it does return.

Docs: CLI reference (command table + Git-workflow section), the new endpoint in the Control Plane API reference, and a pointer from the staging-environments section of the deployment-environments page.

Verification

cargo fmt, cargo clippy --all-targets and cargo build clean. Both commands were driven end-to-end against a stub HTTP server, confirming method, path, body, Authorization scheme, the table and --json rendering, and the new ENABLED column.

---

Generated by Claude Code

[claude]

Claude finished @paveltiunov's task in 2m 56s —— View job

---

Review: looks good to merge — 0 blocking, 1 medium, 2 low (4 inline comments)

Full review

• Gather context (diff, data_model.rs, output.rs, embed.rs precedent, docs)
• Code quality / correctness
• Security
• Testing
• Documentation
• Post inline comments

What's good

• set_branch_enabled is the right factoring — one helper, two thin Cmd arms, and it mirrors embed enable-dashboard/disable-dashboard exactly, including the ctx.json branch.
• The branch name travels in the JSON body, not the URL path, so no path-injection/encoding concern; only the i64 deployment id is interpolated into the URL. Authorization handling is unchanged (inherited from Client).
• Success messages are actionable — the enable path points at cube environments list … --type staging, which is where the credentials actually are.
• Docs are appropriately surgical: a table row, a short ## Data model Git workflow paragraph, a pointer from the existing staging-environments section, and one new endpoint section. The new anchor #buildapiv1deploymentsdeployment_idbranchesstaging-environment matches the transformation used by the existing #apiv1deploymentsdeployment_idenvironments link in the same file. The <Info> note about the /build prefix is a genuinely useful catch.

Findings

Medium — ENABLED/PARENT columns can silently render blank (data_model.rs:403-406)

output::field returns "" for both a missing key and null. If the branches endpoint omits isStagingEnvironmentEnabled on branches that were never toggled (rather than returning false), the column reads blank — the same failure mode this PR is fixing for isDefault/isCurrent, but harder to spot because blank is a plausible rendering of "not enabled". Since the endpoint lives in the enterprise repo, this can't be verified here; worth confirming against a real response rather than the stub. Same question for parentBranch on a root branch.

Also worth a thought: dropping DEFAULT/CURRENT removes the only place the CLI surfaced which branch is the deploy branch. If the response carries an equivalent field, keeping a column for it would help, since merge-to-default behavior hinges on it.

Low — stale command in the doc comment (data_model.rs:242): cube environments list --type staging omits the required deployment positional; the success message at line 263 gets it right.

Low — "Cube Cloud" in user-facing help text (data_model.rs:107, :241): docs-mintlify/CLAUDE.md marks it legacy naming. The new docs prose correctly says "the Cube UI"; the --help strings still say "Cube Cloud".

Notes, not asks

• The API supports branchId as an alternative to branchName (documented in the new reference section), but the CLI only exposes the name. Fine — names are what a CI script has — just flagging the deliberate asymmetry.
• No new tests. The crate only has unit tests for pure helpers (util.rs, telemetry.rs, update.rs) and no command-level harness, so this is consistent with existing practice — but the PR checklist claims "Tests for the changes have been added", which doesn't match what's in the diff. The stub-server verification described in the PR body is the real coverage here; consider saying so instead of ticking that box.
• These commands hard-fail on a tenant without cubedevinc/cubejs-enterprise#13535 with whatever the 404 body is. That's acceptable for a CLI tracking the control plane, and the docs note the dependency indirectly, but a version-gated hint isn't there if you want one later.
• No performance or resource concerns: one PUT per invocation, no new state.
  • branch claude/branch-enable-disable-cli-hvlaxq

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
cubed3	🟢 Ready	View Preview	Jul 31, 2026, 12:32 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[claude]

output::field returns an empty string for both a missing key and null, so if the branches endpoint omits isStagingEnvironmentEnabled for not-yet-toggled branches (rather than returning false), ENABLED renders blank — the exact failure mode this change is fixing for isDefault/isCurrent, just harder to notice because blank is plausible for "not enabled". Same for parentBranch on a root branch.

Since the endpoint lives in the enterprise repo, could you confirm against a real (non-stub) response that both keys are always present on every branch object, including branches never toggled? If isStagingEnvironmentEnabled can be absent, a blank cell will be indistinguishable from false.

Separately: dropping DEFAULT/CURRENT also drops the only place the CLI surfaced which branch is the deploy branch. If the response carries an equivalent (e.g. isDeployBranch/isMain), it'd be worth keeping a column for it — merge-to-default behavior depends on knowing it.

[claude]

Nit: environments list takes the deployment id as a required positional, so this command as written would fail. The success message below (line 263-265) has it right.

Suggested change

	/// branches are the ones `cube environments list --type staging` reports. Only
	/// branches are the ones `cube environments list <deployment> --type staging`

[claude]

Correcting the suggestion above — it dropped the trailing reports. Only. Use:

Suggested change

	/// branches are the ones `cube environments list --type staging` reports. Only
	/// branches are the ones `cube environments list <deployment> --type staging`
	/// reports. Only

[claude]

docs-mintlify/CLAUDE.md lists "Cube Cloud" as legacy naming that shouldn't be used in new content. The new docs text correctly says "the Cube UI"; this help string (and the module doc at line 241) still says "Cube Cloud", and --help output is user-facing too. Worth aligning both to "the Cube UI".

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
cubed3	🟡 Building	–	Jul 31, 2026, 12:31 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.