`btd` outputs text rather than (no) targets when no targets are impacted
cbarrete opened this issue · comments
When a change causes no targets to require a rebuild, the output of btd
is not a valid list of targets:
> supertd btd --cells cells.json --changes changes.txt --base base.jsonl --diff diff.jsonl
2024-02-27T21:53:31.074644Z INFO Starting reading cells at 0.000s
2024-02-27T21:53:31.074679Z INFO Starting reading changes at 0.000s
2024-02-27T21:53:31.074692Z INFO Starting reading base at 0.000s
2024-02-27T21:53:31.094598Z INFO Starting validating universe at 0.020s
2024-02-27T21:53:31.094620Z INFO Starting reading diff at 0.020s
2024-02-27T21:53:31.101620Z INFO Starting immediate changes at 0.027s
2024-02-27T21:53:31.103091Z INFO Starting error validation at 0.028s
2024-02-27T21:53:31.103140Z INFO Starting recursive changes at 0.028s
2024-02-27T21:53:31.103149Z INFO Starting printing changes at 0.029s
Level 0
2024-02-27T21:53:31.103162Z INFO Starting finish with 0 immediate changes, 0 total changes at 0.029s
where Level 0
is written to stdout
and the rest to stderr
. This is a (minor) inconvenience because we cannot directly pass that output to buck2 build
/buck2 test
as suggested in the README. Is this expected behavior? If so, can we expect that output to be stable (because right now I explicitly check against Level 0
to check if targets need to be run or not, which seems fragile)?
I misdiagnosed this one, Level X
is always in the output, so the correct approach is to use one of the JSON output flags and parse that instead.
It would be nice to have a way to dump just the targets to stdout, but it's workable for now.
Yep, I would encourage anyone who wants to consume the output to use the JSON - sooner or later the distance tends to come into play and I don't want people parsing that from stdout. But I'm not averse to a --quiet option which just prints the targets that have changed and no levels or anything.