Leo Famulari <l...@famulari.name> writes: > On Tue, Aug 28, 2018 at 09:57:49AM +0200, Ricardo Wurmus wrote: >> I commented specifically on Leo’s statement about build debugging on >> Cuirass: >> >> “I don't actually do any build debugging with Berlin yet because I >> don't know how to use the interface effectively.” >> >> This did not sound like a severe problem with Cuirass to me, but rather >> a problem that could be fixed by adding minor features to Cuirass like >> the display of build logs. Leo, could you please tell us what missing >> feature in the Cuirass web interface is the most urgent for you to use >> the interface effectively? > > My apologies in advance if these features already exist in the Cuirass > web interface! I didn't find them yet. > > I mostly use Hydra for two things: > > 1) I use it to manage large branch re-builds (e.g. core-updates) by > looking at the lists of failed builds for the lastest evaluation of that > particular "jobset" (i.e. Git branch). > > Hydra gives a list of tabs like this that are helpful: > > Aborted jobs (2) > Newly failing jobs (2) > Newly succeeding jobs (1) > New jobs (29) > Removed jobs (23) > Still failing jobs (2425) > Still succeeding jobs (20470) > Queued jobs (675) > Inputs > > I might also compare the evaluation to another evaluation of the same > jobset, or against another jobset (usually master). > > The concept of "dependency failures" and their reporting is also really > helpful (i.e "foo was not built because its dependency bar failed").
Right, these are all indispensible tools. > Also, I use the Hydra web interface to start jobset evaluations and > restart particular package builds, and to restart all builds that were > skipped due to dependency failures. These are too, although "restart all dependency failures", which I hastily added, is too crude of a tool in my opinion. I've since cooked up a PostgreSQL transaction which does something better: restart all dependency failures that were caused by a particular failed derivation. That should be what we aim for in Cuirass, I think. > 2) Checking build logs of a particular package to see if a failure or > success is reproducible on the build farm. Yes, this too. Mark