Description
Several update commands (e.g., oci bv backup update) prompt for confirmation interactively. When run in a non-TTY environment (CI pipeline, SSH session, script), the prompt is invisible and the command hangs indefinitely with no output, waiting for input that will never come.
Steps to Reproduce
Run an update command in a non-TTY context (e.g., a CI runner, SSH piped command, or script):
# Hangs silently — prompt is invisible in non-TTY:
oci bv backup update --volume-backup-id $ID --display-name "new-name"
The command blocks forever because it's waiting for a y/n confirmation that can never be provided in a non-interactive context.
Expected Behaviour
Either:
- Auto-detect non-TTY and skip the confirmation (like
apt-get -y or docker rm), OR
- Error out immediately with a clear message:
"This command requires confirmation. Use --force to skip the prompt.", OR
- Document
--force prominently in the basic usage line, not buried deep in --help output.
Actual Behaviour
- The command hangs silently with no output.
- The
--force flag exists but is only discoverable via oci bv backup update --help deep in the option list.
- Users unfamiliar with OCI CLI patterns may spend significant time debugging what appears to be a network hang or API timeout.
Affected Commands
This pattern affects multiple update commands across the CLI that use click.confirm() with a force flag. The oci bv backup update command is one example; others likely exist.
Impact
In CI/CD pipelines, this causes task timeouts that are difficult to diagnose because there's no error output — just silence.
Suggested Fix
- Add non-TTY detection (e.g.,
sys.stdin.isatty()) and either auto-accept or error out with a message directing users to --force.
- Alternatively, make
--force the documented default for update commands in non-interactive contexts (similar to how apt-get requires -y for non-interactive use).
- At minimum, ensure the
--force flag is mentioned in the basic usage line, not just in the detailed help.
Description
Several
updatecommands (e.g.,oci bv backup update) prompt for confirmation interactively. When run in a non-TTY environment (CI pipeline, SSH session, script), the prompt is invisible and the command hangs indefinitely with no output, waiting for input that will never come.Steps to Reproduce
Run an update command in a non-TTY context (e.g., a CI runner, SSH piped command, or script):
The command blocks forever because it's waiting for a
y/nconfirmation that can never be provided in a non-interactive context.Expected Behaviour
Either:
apt-get -yordocker rm), OR"This command requires confirmation. Use --force to skip the prompt.", OR--forceprominently in the basic usage line, not buried deep in--helpoutput.Actual Behaviour
--forceflag exists but is only discoverable viaoci bv backup update --helpdeep in the option list.Affected Commands
This pattern affects multiple
updatecommands across the CLI that useclick.confirm()with a force flag. Theoci bv backup updatecommand is one example; others likely exist.Impact
In CI/CD pipelines, this causes task timeouts that are difficult to diagnose because there's no error output — just silence.
Suggested Fix
sys.stdin.isatty()) and either auto-accept or error out with a message directing users to--force.--forcethe documented default for update commands in non-interactive contexts (similar to howapt-getrequires-yfor non-interactive use).--forceflag is mentioned in the basic usage line, not just in the detailed help.