Auto power-on after resize and add 'nodisk' confirmation option

[gwpl]

Summary

AI Agent with Greg: We got caught with our droplet's pants down — resized it, went to SSH in, and found it sitting there powered off like a server that took an unauthorized coffee break. ☕🔌 Meanwhile, the disk resize nearly ate our ability to scale back down. Two papercuts, one patch.

• Auto power-on after resize — DigitalOcean leaves droplets powered off after resize (no API flag exists to change this). The command now automatically powers the droplet back on with progress polling, instead of leaving users to discover a cold droplet and manually run dropkit on.

• nodisk confirmation escape hatch — When disk resize would increase disk size, the confirmation prompt offers yes/nodisk/no instead of yes/no. This supports the common workflow of temporarily scaling up CPU/RAM (e.g. for a heavy build) and scaling back down later — which requires NOT resizing the disk (disk resize is permanent and blocks future downsizing).

Use case: temporary scale-up

# Scale up for a build — "nodisk" keeps it reversible
$ dropkit resize my-box --size s-4vcpu-8gb
...
Are you sure you want to resize this droplet? [yes/nodisk/no] (no): nodisk
Disk resize skipped — CPU/RAM only (you can resize back down later)
...
✓ Resize completed successfully

Powering on droplet...
✓ Power on action started (ID: 3105287233)
Waiting for droplet to power on...
✓ Droplet powered on successfully

Droplet my-box has been resized to s-4vcpu-8gb and is now active

# Later, scale back down — works because disk was never resized
$ dropkit resize my-box --size s-1vcpu-1gb

Technical notes

• The nodisk option only appears when relevant: disk flag is true (default) AND the new size has a larger disk
• Power-on uses the same pattern as dropkit on: 120s timeout, action ID validation, console.status() spinner
• If the power-on action ID can't be obtained, falls back to a warning with manual instructions
• Confirmed via DigitalOcean API spec: no power_on_after_resize parameter exists — two sequential API calls (resize → power_on) is the only path

Test plan

• uv run ruff check dropkit/main.py — all checks passed
• uv run ruff format --check dropkit/main.py — already formatted
• uv run ty check dropkit/main.py — all checks passed
• uv run pytest tests/ -v — 288 tests passed, 31% coverage (above 29% minimum)
• Manual test: dropkit resize <name> --size <bigger> — verify nodisk option appears, auto power-on works
• Manual test: dropkit resize <name> --size <bigger> --no-disk — verify nodisk option does NOT appear (already skipping disk)
• Manual test: dropkit resize <name> --size <same-disk-size> — verify nodisk option does NOT appear (no disk change)
• Manual test: resize then confirm droplet is active without needing dropkit on

🤖 Generated with Claude Code — your friendly neighborhood security-conscious AI, now also a sysadmin who remembers to turn the lights back on

Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com

[ret2libc]

Can't you use dropkit resize --no-disk test-resize instead of adding a new option? This will resize the droplet without resizing the disk.

[gwpl]

Greg:

TL;DR — Yes, --no-disk works technically. This PR is solving a TUI UX / cognitive overhead problem, consistent with dropkit's purpose of making things easier for users than using doctl directly.

Let me unpack my thinking here :)

• Not all dropkit users are DigitalOcean power users — and that's kind of the point of dropkit
• The fact that you must not resize disk in order to preserve the ability to downsize later is non-obvious. It's a DigitalOcean implementation detail that catches people off guard
• The existing --no-disk flag works, but it requires users to already know this gotcha before they hit Enter

From a TUI UX perspective, nodisk as an inline option is the most forgiving design — it surfaces the information at decision time, right when the user sees "Disk resize is PERMANENT." Compare the two experiences:

With nodisk option: User sees the warning, sees the escape hatch, picks it. Done in one flow.

Without: User sees the warning, panics, cancels, has to remember --no-disk, re-runs the command. Extra cognitive load every time.

That said, I totally get that "where to draw the line on hand-holding in the CLI" is a judgment call. If you'd prefer to keep it flag-only, an alternative would be a more explicit warning like: "⚠ Disk resize is permanent — you will not be able to downsize later. Re-run with --no-disk to skip disk resize." Worse UX in my opinion (why make the user restart when we can handle it inline?), but not the end of the world either.

Ultimately my concern is about cognitive-overloaded peers who picked dropkit specifically to reduce the overhead of working with doctl directly — making them memorize flags for every footgun somewhat defeats that purpose 😄

[DarkaMaul]

Just my 2 cents here - maybe I would instead display a warning here to educate instead of the new option nodisk.
If I'm not a power user, then I don't know what nodisk means anyway.

Ok - I read the code, and the warning is already present there...

[ret2libc]

what if we make disk/no-disk an interactive option in case it was not explicitly specified by the user? Something like the size. So instead of disk/no-disk being a boolean, it would be a True/False/None and it would be interactively asked only if it was None.

[gwpl]

AI Assistant: Great suggestion! 🎯 Implemented exactly this.

--disk/--no-disk is now a tri-state (True/False/None). When neither flag is passed, the user gets an interactive question — consistent with how region, size, and image are already handled:

Disk resize is PERMANENT and cannot be undone.
Skipping disk resize keeps the option to downsize later.
Resize disk too? [yes/no] (no): 

Defaults to "no" (safe side — preserves ability to downsize). The question only appears when the new size has a different disk size.

The old nodisk escape hatch in the confirmation prompt is removed — this is cleaner and more idiomatic for the CLI. Pushed as 6a73fd8.