Skip to content

feat: show the disabled state of deployment targets and workers - #732

Draft
NickJosevski wants to merge 1 commit into
nj/issue-311from
nj/issue-311-show-disabled
Draft

NickJosevski wants to merge 1 commit into
nj/issue-311from
nj/issue-311-show-disabled

Conversation

@NickJosevski

@NickJosevski NickJosevski commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

Stacked on #694 — merges into nj/issue-311, not main. Independent of #731; they touch no files in common.

Answers the "should view/list surface the disabled state?" question on #694: yes. Without it enable/disable has no read-back — the only way to confirm a toggle was the web UI.

What changed

The state is added to every surface that already reports on a machine:

table json basic
deployment-target list IS DISABLED column IsDisabled — (name only)
deployment-target view IS DISABLED column IsDisabled Disabled: true
worker list IS DISABLED column IsDisabled — (name only)
worker view IS DISABLED column IsDisabled Disabled: true

The per-type views (deployment-target ssh view, worker listening-tentacle view, and the rest) gain a Disabled row — each set shares one ViewRun, so that is one line per resource.

Two deliberate choices:

  • Follows tenant list, which already prints an IS DISABLED column — this is not a new idea in the CLI.
  • One name everywhere: IsDisabled in JSON, IS DISABLED in tables, Disabled in basic output — all named after the API field, rather than inverting to "Enabled" on some surfaces.

Workers are included because #731 adds worker enable|disable; shipping that without a way to see the result would recreate the gap this PR closes. Say the word and I'll split them.

Test evidence

New tests, all end-to-end through the root command against the mock HTTP server:

  • pkg/cmd/target/list/list_test.go, pkg/cmd/target/view/view_test.go
  • pkg/cmd/worker/list/list_test.go, pkg/cmd/worker/view/view_test.go
  • pkg/cmd/target/shared/view_test.go, pkg/cmd/worker/shared/view_test.go — one per-type view each, covering the shared ViewRun row.

Each asserts the table column, the JSON field and (where applicable) the basic-output line, for both an enabled and a disabled machine.

go build ./... clean; go test ./pkg/... all pass, no failures. gofmt/go vet report only pre-existing issues in files this PR does not touch. No live server is required.

Note on the rebase

Rebased onto current main, which had rewritten target/list, target/view, worker/list and worker/view (#717 and the worker endpoint fixes). Two things to know:

  • The disabled-state additions were re-applied on top of main's newer code, so the type columns keep main's describeTargetType / describeWorkerStyle / machinescommon.GetCommunicationStyle versions.
  • main already has internal (package list / package view) test files at list_test.go and view_test.go in all four directories, so these tests now sit beside them in *_disabled_test.go as external _test packages. In target/view they reuse the rootResource that view_ecs_test.go already defines rather than declaring a second one.

🤖 Generated with Claude Code

`enable`/`disable` had no read-back: nothing in the CLI reported whether a
target or worker was disabled, so the only way to confirm a toggle was the web
UI.

Adds the state to every surface that already reports on a machine:

- `deployment-target list`, `deployment-target view`, `worker list` and
  `worker view` gain an IS DISABLED table column, an IsDisabled JSON field, and
  a "Disabled" line in basic output.
- the per-type views (`deployment-target ssh view`, `worker listening-tentacle
  view`, and the rest) gain a Disabled row; they share one ViewRun each, so
  that is one line per resource.

Follows `tenant list`, which already prints an IS DISABLED column, and names
the concept IsDisabled/IS DISABLED/Disabled after the API field on every
surface.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
@NickJosevski
NickJosevski force-pushed the nj/issue-311-show-disabled branch from 87bb619 to fc852af Compare September 15, 2026 07:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant