Problem
There is no documentation explaining:
- What
[warning] messages the CLI can emit and what they mean
- That warnings are written to stderr and do not affect exit codes
- That there is currently no way to suppress warnings (no
--quiet flag, no log-level config)
- How to handle warnings in CI/CD pipelines
Context
User raised this concern — their pipeline users see CLI warnings and worry they indicate real problems.
CI environments make this worse: In Jenkins, Azure DevOps, Bitbucket Pipelines, and GitHub Actions, stdout and stderr are multiplexed into a single build log. Users cannot distinguish warning lines from normal output. Some CI systems render stderr with error-level formatting (red text), making non-fatal warnings look like failures. Redirecting stderr (2>/dev/null) is not a practical workaround because it also suppresses genuine error messages.
The --debug flag is documented (client_reference/kosli.md, troubleshooting/subshell_stderr.md) but the inverse (reducing output) is not addressed.
Suggested scope
- Add a section to the CLI reference or troubleshooting docs explaining warning behavior: what triggers them, that they're non-fatal, and that they appear in stderr
- Explain the CI multiplexing issue and why warnings appear alongside normal output in build logs
- Document any available workarounds (with caveats)
- Cross-reference with
--debug documentation
- If/when a
--quiet flag is added to the CLI, document it here
Problem
There is no documentation explaining:
[warning]messages the CLI can emit and what they mean--quietflag, no log-level config)Context
User raised this concern — their pipeline users see CLI warnings and worry they indicate real problems.
CI environments make this worse: In Jenkins, Azure DevOps, Bitbucket Pipelines, and GitHub Actions, stdout and stderr are multiplexed into a single build log. Users cannot distinguish warning lines from normal output. Some CI systems render stderr with error-level formatting (red text), making non-fatal warnings look like failures. Redirecting stderr (
2>/dev/null) is not a practical workaround because it also suppresses genuine error messages.The
--debugflag is documented (client_reference/kosli.md,troubleshooting/subshell_stderr.md) but the inverse (reducing output) is not addressed.Suggested scope
--debugdocumentation--quietflag is added to the CLI, document it here