(address . bug-guix@gnu.org)
87y2wfptj5.fsf@lassieur.org
Cuirass: Some builds fail although their log file ends with 'build-succeeded'
- Done
Details
- 4 participants
- Clément Lassieur
- Ludovic Courtès
- Mathieu Othacehe
- Mathieu Othacehe
- Owner
- unassigned
- Submitted by
- Clément Lassieur
- Severity
- normal
C
M
(address . bug-guix@gnu.org)(address . 38232@debbugs.gnu.org)
874kz2vrem.fsf@gmail.com
Hello,
It seems to be also an issue for evaluations that look successful but
are reported as failed, see here:
https://ci.guix.gnu.org/eval/8641/log/raw- mark as failed
https://ci.guix.gnu.org/eval/8725/log/raw- mark as failed
Mathieu
M
(address . bug-guix@gnu.org)(address . 38232@debbugs.gnu.org)
8736emvkie.fsf@gmail.com
Toggle quote (3 lines)
> It seems to be also an issue for evaluations that look successful but
> are reported as failed, see here:
Looking at those evaluation logs, I think there is yet another issue. On
core-updates:
* Evaluation 8747 fails because it cannot build curl
* Next evaluation 8762, considers curl build as previously failed:
Toggle snippet (12 lines)
Computing Guix derivation for 'x86_64-linux'... builder for `/gnu/store/1510sg9h2ivq4841gqm9dhmq5l50a52b-curl-7.66.0' failed previously (cached)
@ build-failed /gnu/store/pqfnxfk5xx0ngc32wlq87vhchh80mnkw-curl-7.66.0.drv - cached--8<---------------cut here---------------end--------------->8---
and fails immediately.
The curl build problem (at 8747 evaluation) seems related to some failed
test case (1242) that I cannot reproduce locally.
Will all future evaluations re-use this cache and also fail immediately?
If yes, how can we unblock the situation?
Mathieu
L
(name . Clément Lassieur)(address . clement@lassieur.org)(address . 38232@debbugs.gnu.org)
87y2wei4cn.fsf@gnu.org
Hi Clément,
Clément Lassieur <clement@lassieur.org> skribis:
Perhaps the build failed (transient failure or something) but was
eventually restarted either as a dependency of some other build or
manually on berlin. In that case Cuirass may be unaware that the build
eventually succeeded, hence the discrepancy.
Thanks,
Ludo’.
C
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 38232@debbugs.gnu.org)
877e3xjevh.fsf@lassieur.org
Hi Ludovic,
Toggle quote (5 lines)
> Perhaps the build failed (transient failure or something) but was
> eventually restarted either as a dependency of some other build or
> manually on berlin. In that case Cuirass may be unaware that the build
> eventually succeeded, hence the discrepancy.
Thank you for the explanation. Would it make sense to copy the log file
to some other place when the build is done? The web interface would
fetch it there, and we would be sure it matches the associated Cuirass
build.
Clément
L
(name . Clément Lassieur)(address . clement@lassieur.org)(address . 38232@debbugs.gnu.org)
87blt9gcjn.fsf@gnu.org
Hello,
Clément Lassieur <clement@lassieur.org> skribis:
Toggle quote (10 lines)
>> Perhaps the build failed (transient failure or something) but was
>> eventually restarted either as a dependency of some other build or
>> manually on berlin. In that case Cuirass may be unaware that the build
>> eventually succeeded, hence the discrepancy.
>
> Thank you for the explanation. Would it make sense to copy the log file
> to some other place when the build is done? The web interface would
> fetch it there, and we would be sure it matches the associated Cuirass
> build.
Build logs are kept by guix-daemon under /var/log/guix/drvs. They are
indexed by derivation, meaning that there can be only one log per
derivation.
This is a limitation in cases where builds are retried. Initially
Mathieu Lirzin thought about keeping logs elsewhere so we could
distinguish between several attempts to build a derivation. However,
that’s kind of redundant with what the daemon does, and not frequently
useful.
Now, it is indeed useful in some cases, so we could do something like
you describe.
Thanks,
Ludo’.
M
(address . 38232-done@debbugs.gnu.org)
8735wj5qn1.fsf@gnu.org
Hello,
This is no longer an issue on Cuirass master.
Thanks,
Mathieu
Closed
?