When QUARTO_LOG_LEVEL=DEBUG is set (or GitHub Actions debug mode auto-elevates the level), every Quarto subcommand prepends a bare Quarto version: X.Y.Z line to stderr — including commands whose stderr is the data channel that consumers parse, such as quarto list extensions.
Reproduction:
$ QUARTO_LOG_LEVEL=DEBUG quarto list extensions
Quarto version: 1.9.37
Id Version Contributes
quarto-ext/fontawesome 1.3.0 shortcodes
The same line shows up on error output of other commands (quarto inspect, quarto render with a fatal error, etc.).
Source of the diagnostic:
|
debug("Quarto version: " + quartoConfig.version()); |
The log level is auto-elevated to DEBUG when GitHub Actions runs with debug logging on (RUNNER_DEBUG=1):
|
// Determine log level with priority: explicit args > QUARTO_LOG_LEVEL > GitHub Actions debug mode |
|
let level = args.ll || args["log-level"] || Deno.env.get("QUARTO_LOG_LEVEL"); |
|
|
|
// Enable DEBUG logging when GitHub Actions debug mode is on (RUNNER_DEBUG=1) |
|
// Can be overridden by explicit --log-level or QUARTO_LOG_LEVEL |
|
if (!level && isGitHubActions() && isVerboseMode()) { |
|
level = "DEBUG"; |
|
} |
Impact: any tool that parses Quarto CLI stderr breaks under DEBUG. The R quarto package's quarto_list_extensions() parses quarto list extensions stderr with read.table(header = TRUE); under DEBUG, the prepended version line is consumed as the header row and downstream code fails with argument 1 is not a vector. We hit this in quarto-dev/quarto-r CI any time the workflow is re-run with debug logging.
We could:
- Route this diagnostic through the structured log handler (with level prefix and timestamp) so it lands in
--log output rather than as a bare line on stderr, or
- Gate it on
TRACE rather than DEBUG, since DEBUG is auto-enabled by CI debug mode and a number of code paths legitimately want DEBUG without the version preamble polluting stdout/stderr consumers.
Either approach keeps the diagnostic available without breaking programmatic consumers of CLI output.
When
QUARTO_LOG_LEVEL=DEBUGis set (or GitHub Actions debug mode auto-elevates the level), every Quarto subcommand prepends a bareQuarto version: X.Y.Zline to stderr — including commands whose stderr is the data channel that consumers parse, such asquarto list extensions.Reproduction:
The same line shows up on error output of other commands (
quarto inspect,quarto renderwith a fatal error, etc.).Source of the diagnostic:
quarto-cli/src/quarto.ts
Line 161 in 36e2232
The log level is auto-elevated to
DEBUGwhen GitHub Actions runs with debug logging on (RUNNER_DEBUG=1):quarto-cli/src/core/log.ts
Lines 104 to 111 in 36e2232
Impact: any tool that parses Quarto CLI stderr breaks under
DEBUG. The Rquartopackage'squarto_list_extensions()parsesquarto list extensionsstderr withread.table(header = TRUE); underDEBUG, the prepended version line is consumed as the header row and downstream code fails withargument 1 is not a vector. We hit this inquarto-dev/quarto-rCI any time the workflow is re-run with debug logging.We could:
--logoutput rather than as a bare line onstderr, orTRACErather thanDEBUG, sinceDEBUGis auto-enabled by CI debug mode and a number of code paths legitimately wantDEBUGwithout the version preamble polluting stdout/stderr consumers.Either approach keeps the diagnostic available without breaking programmatic consumers of CLI output.