Tests fail without Valgrind

[Ludovic Courtès]

Hello!

[Cc: hydra-users at gnu.org.]

Simon Josefsson <simon at josefsson.org> writes:

> ludo at gnu.org (Ludovic Courtès) writes:
>
>> Which leads to another question: do you receive the build notifications
>> from Hydra?  If you do receive them but don’t look at them, how do you
>> think they could be improved to be more useful to you?
>
> Can we disable e-mail notifications for coverage failures?

Yes.  Done.

> Ideally, I would want notification to work something like this:
> designate one platform as the trigger platform.  If building a revision
> on that platform fails, send ONE notification, and don't bother send any
> more notifications about any failures (possibly it could complain once
> per week if the trigger platform is not building for a long time).  If a
> revision has been built on the trigger platform, and fails to build on
> some other platform, send ONE notification for failures on that
> platform, and don't bother send any more notifications for that platform
> until it is working.

IIUC what you suggest, that’s similar to what has been happening for
some time now: notifications are sent when the status of a
job x platform changes (SUCCEEDED -> FAILED, or FAILED -> SUCCEEDED).
So you get one message when the package breaks and you don’t get any new
message until it’s fixed.  (When we started using Hydra, you would get
one message each time a build fails, which quickly led to flooding.)

There’s currently no notion of a “trigger platform”, though, but I don’t
understand its role in your suggestion.  Can you clarify what you want
to achieve and how the trigger platform would help?

> To be clear, I don't see any point in the FAILED->SUCCEEDED
> notifications at all,

OK.  I personally find it useful: it gives feedback when I fix
something, and I start worrying if I don’t get the message.  :-)

> as long as it complains every week if some platform is still broken.

Don’t forget there’s also a web page.  Basically, I see notifications as
a way of getting quick feedback so that one can react quickly.  In cases
where quick response is not needed, it’s probably enough to check the
status page (e.g., <http://hydra.nixos.org/jobset/gnu/gnutls-master>)
once in a while.

> Implementation wise, I suspect notification needs to be separated from
> the build process to implement complex logic above sufficiently well.

The build process is handled by Nix while Hydra does the checkouts,
triggers and schedules builds, and provides the web interface and email
notifications.

Thanks for your feedback!

Please use the new hydra-users at gnu.org mailing list for complaints,
feature requests, etc.

Ludo’.