feat: icp canister create --with-icp

[adamspofford-dfinity]

No description provided.

[Copilot]

Pull request overview

Adds ICP-funded canister creation through the cycles minting canister.

Changes:

• Adds the --with-icp funding option.
• Implements ICP transfer, CMC notification, retries, and recovery guidance.
• Adds CMC interfaces, documentation, and integration coverage.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
CHANGELOG.md	Records the new feature.
docs/reference/cli.md	Documents --with-icp.
crates/icp-cli/tests/canister_create_tests.rs	Tests ICP-funded creation.
crates/icp-cli/src/operations/create.rs	Implements CMC-funded creation.
crates/icp-cli/src/commands/deploy.rs	Preserves cycles funding for deployments.
crates/icp-cli/src/commands/canister/create.rs	Adds CLI funding selection.
crates/icp-canister-interfaces/src/cycles_minting_canister.rs	Defines CMC request and response types.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[marc0olo]

Deferring approval to Linwei/Raymond since this adds a new user-facing flag and payment path. A few points to resolve first:

1. When to use --with-icp isn't discoverable. The "only needed for restricted system subnets" guidance is only in the CHANGELOG. --help explains what it does (CMC vs cycles ledger) but not when, so a user sees --with-icp next to --cycles with no basis to choose. Move that sentence into the arg doc comment so it surfaces in --help.

2. Should --with-icp require --subnet? In create_cmc, when --subnet is omitted, get_subnet() falls back to a random subnet from get_default_subnets(), which won't include restricted system subnets — so --with-icp alone is just a slower/pricier path to the same default placement, with no benefit. Given restricted subnets are the intended use case, should we enforce --subnet when --with-icp is set (clap requires), rather than only documenting the pairing?

3. No test for the --with-icp + --subnet combo — the intended workflow. Precision rejection and the timeout/recovery path are also untested.

Minor: cycles() panics on the Icp variant, so it's an invariant-by-panic that's only safe because create() early-returns to create_cmc — a future caller/reorder would compile fine and panic at runtime. And --with-icp N transfers N ICP per canister for project creation.

[adamspofford-dfinity]

We don't need to add a restriction that it only be used for the use case specifically envisioned. canister create only operates on one canister so 'per canister' isn't a thing (nor is this different from cycles). The panic is intentional: it indicates programmer error.

I can't see a good way of testing the retry loop.

[lwshang]

Pushed a follow-up commit hardening the --with-icp path:

• Recovery command is now paste-ready. On timeout/interrupt, the printed notify_create_canister command now includes the --identity/--network/--environment flags from the original call (single-quoted for the shell). Previously it silently used defaults — which would fail for exactly the non-default-identity case, since the CMC subaccount is derived from the caller.
• Quieter wait logging. The CMC wait now logs at info! and only when the status changes, instead of emitting a warn! every 2s for the full minute.
• Idempotent funding transfer. The transfer now sets a fixed created_at_time and retries transient transport failures. A lost response is deduplicated by the ledger (TxDuplicate) and returns the original block index, rather than erroring out and stranding the transferred ICP.

Added a shell_quote unit test and extended the recovery-command test to cover the appended flags. Also merged latest main.