unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Continuous integration - automatic EMAIL
@ 2020-10-07 15:39 Danny Milosavljevic
  2020-10-07 15:52 ` Mathieu Othacehe
  2020-10-07 22:20 ` raingloom
  0 siblings, 2 replies; 6+ messages in thread
From: Danny Milosavljevic @ 2020-10-07 15:39 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

Hi,

please, let's improve building and testing processes.

Please, can we have the build servers send build failures to guix-devel
instead of hoping that people check manually?  I have other things to do
in my life than to poll random servers every few hours.

If you don't want to send e-mail on all failures (probably an overwhelming
flood at first--that's how bad the current state is!), then I suggest to:

Daily do, on each supported architecture (and I mean those packages
specifically--it's not an example stand-in):

  guix pull
  guix build glibc || mail guix-devel@gnu.org -s "glibc failed"
  guix build gtk+ || mail guix-devel@gnu.org -s "gtk+ failed"
  guix build gnome-desktop || mail guix-devel@gnu.org -s "gnome-desktop failed"

and I mean automatically--not triggered manually by a person.

Maybe I'm missing something--but the amount of manual fiddling I have to do
which a computer could automate perfectly well is REALLY inefficient.

There's nothing fundamental missing--why can't the last obvious step be
added so it is actually automatic?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Continuous integration - automatic EMAIL
  2020-10-07 15:39 Continuous integration - automatic EMAIL Danny Milosavljevic
@ 2020-10-07 15:52 ` Mathieu Othacehe
  2020-10-12 12:06   ` Ludovic Courtès
  2020-10-07 22:20 ` raingloom
  1 sibling, 1 reply; 6+ messages in thread
From: Mathieu Othacehe @ 2020-10-07 15:52 UTC (permalink / raw)
  To: Danny Milosavljevic; +Cc: guix-devel


Hello Danny,

> Please, can we have the build servers send build failures to guix-devel
> instead of hoping that people check manually?  I have other things to do
> in my life than to poll random servers every few hours.

That feature is definitely on my list. Fixing Cuirass and improving the
build throughput is already a hard task, but I'm getting there. In the
meantime, if people want to join Cuirass debugging party, they are more
than welcome!

Thanks,

Mathieu



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Continuous integration - automatic EMAIL
  2020-10-07 15:39 Continuous integration - automatic EMAIL Danny Milosavljevic
  2020-10-07 15:52 ` Mathieu Othacehe
@ 2020-10-07 22:20 ` raingloom
  1 sibling, 0 replies; 6+ messages in thread
From: raingloom @ 2020-10-07 22:20 UTC (permalink / raw)
  To: guix-devel

On Wed, 7 Oct 2020 17:39:35 +0200
Danny Milosavljevic <dannym@scratchpost.org> wrote:

> Hi,
> 
> please, let's improve building and testing processes.
> 
> Please, can we have the build servers send build failures to
> guix-devel instead of hoping that people check manually?  I have
> other things to do in my life than to poll random servers every few
> hours.
> 
> If you don't want to send e-mail on all failures (probably an
> overwhelming flood at first--that's how bad the current state is!),
> then I suggest to:
> 

Could an RSS feed work?

Or just don't send it to devel, make a new list for it. Or send it to
bugs.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Continuous integration - automatic EMAIL
  2020-10-07 15:52 ` Mathieu Othacehe
@ 2020-10-12 12:06   ` Ludovic Courtès
  2020-10-12 19:12     ` zimoun
  0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2020-10-12 12:06 UTC (permalink / raw)
  To: Mathieu Othacehe; +Cc: guix-devel

Hi!

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> Please, can we have the build servers send build failures to guix-devel
>> instead of hoping that people check manually?  I have other things to do
>> in my life than to poll random servers every few hours.
>
> That feature is definitely on my list. Fixing Cuirass and improving the
> build throughput is already a hard task, but I'm getting there. In the
> meantime, if people want to join Cuirass debugging party, they are more
> than welcome!

Here’s my contribution: a Guile module using Mailutils to compose and
send messages:

  https://wiki.gnu.tools/git/gnu-tools-wiki/tree/code/modules/email.scm

The only thing that’s missing is a proper setup for outgoing mail from
guix.gnu.org, presumably with OpenSMTPD.  The config is here:

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm

If someone would like to help, please send a patch!  :-)  We can also
adjust the MX record for guix.gnu.org at our will:

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/dns.scm


Caveat: my experience with Hydra is that you immediately receive too
much mail.  Initially Hydra would send one message per failed build,
which was then changed to one message at each status change (from
“success” to “failure” and vice versa), but that was still too much.  I
think eventually it was change to email only the committers of the
offending commits, which is probably the best option.

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Continuous integration - automatic EMAIL
  2020-10-12 12:06   ` Ludovic Courtès
@ 2020-10-12 19:12     ` zimoun
  2020-10-13 13:59       ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: zimoun @ 2020-10-12 19:12 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Guix Devel, Mathieu Othacehe

Hi,

On Mon, 12 Oct 2020 at 14:06, Ludovic Courtès <ludo@gnu.org> wrote:

> >> Please, can we have the build servers send build failures to guix-devel
> >> instead of hoping that people check manually?  I have other things to do
> >> in my life than to poll random servers every few hours.
> >
> > That feature is definitely on my list. Fixing Cuirass and improving the
> > build throughput is already a hard task, but I'm getting there. In the
> > meantime, if people want to join Cuirass debugging party, they are more
> > than welcome!

[...]

> Caveat: my experience with Hydra is that you immediately receive too
> much mail.  Initially Hydra would send one message per failed build,
> which was then changed to one message at each status change (from
> “success” to “failure” and vice versa), but that was still too much.  I
> think eventually it was change to email only the committers of the
> offending commits, which is probably the best option.

If "guix weather -m" is improved, does it fill the gap?  Because it is
exactly doing what is required, isn't?  But it is not suitable for
this purpose because of UI.  I mean:

--8<---------------cut here---------------start------------->8---
$ cat /tmp/spec.scm
(specifications->manifest (list "emacs" "gcc-toolchain" "python-umap-learn"))

$ guix weather -m /tmp/spec.scm
computing 49 package derivations for x86_64-linux...
looking for 66 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  97.0% substitutes available (64 out of 66)
  at least 340.7 MiB of nars (compressed)
  534.1 MiB on disk (uncompressed)
  0.001 seconds per request (0.0 seconds in total)
  1,768.0 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---

The information is here but I do not know which ones are fine and
which ones are failing.  If an option like "--raw" (or "--plain" or
"--exhaustive" or "--name-it" :-)) could display the status of all the
66 packages, then I think it would ease the detection of the
regresion.  For example,

  OK: emacs
  FAIL: python-umap-learn
  [...]

then it is doable to have a shell script parsing this output and I can
feed "git bisect".  Somehow.

WDYT?

All the best,
simon


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Continuous integration - automatic EMAIL
  2020-10-12 19:12     ` zimoun
@ 2020-10-13 13:59       ` Ludovic Courtès
  0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2020-10-13 13:59 UTC (permalink / raw)
  To: zimoun; +Cc: Guix Devel, Mathieu Othacehe

Hi!

zimoun <zimon.toutoune@gmail.com> skribis:

> If "guix weather -m" is improved, does it fill the gap?

I think it helps, but it’s not the same as getting a notification for a
commit you’ve just made.

> Because it is exactly doing what is required, isn't?  But it is not
> suitable for this purpose because of UI.  I mean:
>
> $ cat /tmp/spec.scm
> (specifications->manifest (list "emacs" "gcc-toolchain" "python-umap-learn"))
>
> $ guix weather -m /tmp/spec.scm
> computing 49 package derivations for x86_64-linux...
> looking for 66 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org
>   97.0% substitutes available (64 out of 66)
>   at least 340.7 MiB of nars (compressed)
>   534.1 MiB on disk (uncompressed)
>   0.001 seconds per request (0.0 seconds in total)
>   1,768.0 requests per second
>   'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
>
> The information is here but I do not know which ones are fine and
> which ones are failing.  If an option like "--raw" (or "--plain" or
> "--exhaustive" or "--name-it" :-)) could display the status of all the
> 66 packages, then I think it would ease the detection of the
> regresion.  For example,

You can use ‘--display-missing’:

--8<---------------cut here---------------start------------->8---
$ guix weather --display-missing $(guix package -I |cut -f1)
computing 295 package derivations for x86_64-linux...
looking for 365 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  95.6% substitutes available (349 out of 365)
  at least 2,341.0 MiB of nars (compressed)
  3,865.8 MiB on disk (uncompressed)
  0.061 seconds per request (22.3 seconds in total)
  16.3 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")

Substitutes are missing for the following items:
  /gnu/store/0yjlganb3rw7jp1vw8hbpbbqf1myhmr2-sysstat-12.4.0
  /gnu/store/qnqny5gj6qrg5z1sa4wkcs6858mysvn4-emacs-strace-mode-0.0.2-1.6a69b4b
  /gnu/store/dnlli1380xpz0n939qhfn0kydm2sfpmc-emacs-gitpatch-0.5.1
  /gnu/store/h47f9hrg0d0dshqhk6s3nha0bzy0ihvd-emacs-recutils-1.8
  […]
--8<---------------cut here---------------end--------------->8---

But then that doesn’t allow you to distinguish between failed builds,
things that are not built yet, and “dependency-failed” builds.

‘guix publish’ could perhaps somehow expose failed builds.  And then we
could improve ‘guix weather’ to find about failed dependencies (sort of
like ‘-c’ does actually).

> then it is doable to have a shell script parsing this output and I can
> feed "git bisect".  Somehow.

Yeah, somehow.  :-)

Ludo’.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-10-13 14:35 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-07 15:39 Continuous integration - automatic EMAIL Danny Milosavljevic
2020-10-07 15:52 ` Mathieu Othacehe
2020-10-12 12:06   ` Ludovic Courtès
2020-10-12 19:12     ` zimoun
2020-10-13 13:59       ` Ludovic Courtès
2020-10-07 22:20 ` raingloom

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).