stderr of the running targets can be kept on the disk by
specifying -k option (or by setting
environment variable) to
redo. You can simultaneously
use also -s option (
$REDO_SILENT=1 environment variable)
stderr output, but still keeping it on the disk for
possible further debug investigation. Only the latest build is
kept, previous one is overwritten.
$ redo -xx -k -s build-the-whole-huge-project
Logs are stored in corresponding .redo/tgt.log file. Each line of
it is prefixed with TAI64N
timestamp, that you can decode with
tai64nlocal utility from
daemontools, or similar one:
go get go.cypherpunks.ru/tai64n/cmd/tai64nlocal.
When -k is in use, all environment variables, working directory, command line arguments, start/finish times, duration, participated PIDs, return codes are also saved in corresponding .redo/tgt.log.reg file.
You can view any target’s output with
(possibly piping to
tai64nlocal). -c option also
shows how exactly it was started, when started/finished and how long did
-r option enables recursive serialized indented output. When
redo in parallel, then all
stderr (if no
-silence was enabled) is printed as it appears, mixing output
from all commands, that is hard to read and investigate. Serialized
redo-log output rearranges output. I will take example from
original apenwarr’s idea article. Serialized output will look like this:
$ redo-log -r A A: ...A stuff... A: redo-ifchange J J: > redo J J: > ...J stuff... J: > redo-ifchange X Y X: > > redo X X: > > ...X stuff... X: > > done X J: > > redo Y Y: > > ...Y stuff... Z: > > > redo Z Z: > > > ...Z stuff... Z: > > > done Z Y: > > ...more Y stuff... Y: > > done Y J: > ...more J stuff... J: > done J A: ...more A stuff...
It will output depth first logs. It can rearrange some "events" (redo invocations): failed targets will be at the very end, because they are the most interesting ones for the human.
Pay attention that recursive output is more CPU hungry. Single target
output is literally copying of .redo/tgt.log file to