Every command group configures zerolog to write to os.Stdout (cmd/saucectl/saucectl.go:100), so any WRN/INF line emitted while a command is rendering JSON lands inside the document and breaks a downstream | jq.
Reachable today, for example, with a large --all listing that also asks for JSON:
saucectl authoring testcases list --all -o json | jq . # a WRN line can appear mid-document
PR #1100 works around it locally by holding back that one advisory warning under -o json, but the general problem affects every group that supports -o json (builds, devices, jobs, storage, authoring) and every warning any of them can emit.
Suggested fix: send the logger to os.Stderr. Diagnostics belong there, it fixes every command at once, and it makes -o json safe to pipe by construction.
Why it needs its own change: it alters the output stream for every existing user. Anyone capturing saucectl run output with > log.txt would stop seeing progress lines in that file, so it wants a deliberate decision and a release note rather than riding along in a feature PR.
Every command group configures zerolog to write to
os.Stdout(cmd/saucectl/saucectl.go:100), so anyWRN/INFline emitted while a command is rendering JSON lands inside the document and breaks a downstream| jq.Reachable today, for example, with a large
--alllisting that also asks for JSON:PR #1100 works around it locally by holding back that one advisory warning under
-o json, but the general problem affects every group that supports-o json(builds,devices,jobs,storage,authoring) and every warning any of them can emit.Suggested fix: send the logger to
os.Stderr. Diagnostics belong there, it fixes every command at once, and it makes-o jsonsafe to pipe by construction.Why it needs its own change: it alters the output stream for every existing user. Anyone capturing
saucectl runoutput with> log.txtwould stop seeing progress lines in that file, so it wants a deliberate decision and a release note rather than riding along in a feature PR.