Operations

Creating, updating, and deleting a resource on qibdo Cloud starts a server-side operation that runs to completion in its own time. The CLI turns that into one contract that every mutating command follows, so you never have to ask what a given command does with a long-running change.

Not yet shipped

Mutating commands are still on their way. The contract below is the one they will all follow, and it is documented here because it shapes how the commands are meant to be used.

Wait by default

A mutating command waits for the operation to finish and prints the final resource. The command exits when the change is real, which is what makes it safe to write the obvious thing in a script:

qibdo <service> <resource> create <name>

Nothing after that line has to poll or sleep.

Detach with --async

Pass --async and the command prints the operation id and returns immediately, leaving the work running:

qibdo <service> <resource> create <name> --async

That is the right choice when you are starting several changes at once, or when a step in a pipeline should not block. A detached operation is re-attached later with:

qibdo <service> operations describe <id>

Confirmation on destructive commands

Destructive commands prompt before they act. --yes skips the prompt:

qibdo <service> <resource> delete <name> --yes

In a non-interactive context --yes is required, never assumed. A delete that would have prompted fails instead of guessing, so a script that forgot to opt in stops rather than destroying something quietly. See Running without a terminal for the related --no-input behaviour.

Related

• Command reference
• Errors for what a failed operation reports