bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

宋文武 <iyzsong@envs.net> writes:

> Maxime Devos <maximedevos@telenet.be> writes:
>
>> For example, naev used to work just fine, yet apparently it doesn't
>> anymore: https://issues.guix.gnu.org/65390.
>>
>> Given that Guix has ci.guix.gnu.org, I would expect such new problems
>> to be detected and resolved early, and it was detected by
>> ci.guix.gnu.org, yet going by issues.guix.gnu.org it was never even
>> investigated.
>
> Yes, honestly I only look for build failures from bug reports, not from
> CI if i'm not doing a "request for merge" from another branch.
>
>>
>> (Yes, there is a delay, but that doesn't matter at all, as there's
>> this dashboard <https://ci.guix.gnu.org/eval/668365/dashboard>.)
>
> I found the dashboard inconvenient to use, it show failures for both
> builds and dependencies in the same red color, and can't be searched.
> What I usually do is:
>
> 1. download the job status json with:
>   wget -O jobs.json 'https://ci.guix.gnu.org/api/jobs?evaluation=692229&system=x86_64-linux'
>
> 2. use jq to show package names with build failures:
>   cat jobs.json  | jq '. | map(select(.status == 1)) | .[].name' -r
>
> 3. select interested one to investigate (if doing merge, diff the failures from
> working branch with master).

Maybe we should open Cuirass feature requests on our bug tracker to
remember what would be valuable to implement.

>> Do people really need to report 33% of all jobs
>> (https://ci.guix.gnu.org/eval/668365/dashboard) before those failures
>> are taken seriously, instead of the ‘there don't seem to be that much
>> more build failures from the core-updates/... merge, let's solve them
>> later (i.e., never)’ that seems to be  status quo?
>
> Maybe we can automatically report the failures as bugs, say every 7
> days, and remove a package if it still fail to build in 90 days?

That's sounds reasonable to me.

> As for now, x86_64 master (eval 668365) has 696 build failures, 604
> dependencies failures, 30 unknown (canceld?) failures, total 1330
> failures according to the jobs.json data.
>
> Should we open a bug report for each of those 696 build failures?

I'm not against, though that sounds like a lot of work unless automated.

-- 
Thanks,
Maxim