De: "Jakub Cajka"
> 1. You have a summary of the successes and failures at the end of
the log
> files
> 2. each failed build run of a package ends with 'Done processing $spec
> (failure)'
Ah... missed that, I have been just quickly scanning the log's
first few 100 lines. What tool are you using for the build? mockchain?
It's a quick and dirty script that is a bit smarter than mockchain (knows about
bootstraping and release bumping), but with pretty raw logging facilities. I can attach it
if you want.
I will look at mockchain but given its man page it is far from evident it is possible to
wrap around it in a bootstraping context (and Go packages absolutely need this given all
the cycles between them)
> So it's pretty easy to check what package failed and then
locate the part of
> the log dealing with the last build attempt of this package.
Easy but extremely time consuming. I have nicely structured output
from mockchain(so no need to writer parser for log file(s)), still it is extremely
time consuming, especially when verifying the issues.
I understand, at this point my Go toolchain makes creating and updating Go packages
trivial. The time consuming phase is build log analysis (especially to sort what unit
tests are relevant and what unit tests can not work in a mock env).
Regards,
--
Nicolas Mailhot