public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "Frank Ch. Eigler" <fche@elastic.org>
Cc: Luis Machado <luis.machado@arm.com>,
	Overseers mailing list <overseers@sourceware.org>,
	binutils@sourceware.org,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Adding binutils to the GNU Toolchain buildbot on sourceware
Date: Tue, 26 Apr 2022 00:11:06 +0200	[thread overview]
Message-ID: <YmccekNrHdyGG1Vt@wildebeest.org> (raw)
In-Reply-To: <YmboIgR1iHSN7BVI@elastic.org>

Hi Frank,

On Mon, Apr 25, 2022 at 02:27:46PM -0400, Frank Ch. Eigler wrote:
> > I think we should try to keep builds/checks under 10 minutes, that the
> > checks should be for things that the maintainers think should always
> > be green. So that you get a report about something important breaking
> > within 10 minutes while you still know what you did. Another reason to
> > keep build/check times short is so you can test multiple commits per
> > hour.
> 
> Can we suppress outgoing email notifications about failures?

Yes, buildbot is fairly flexible. At the moment this is how the
reporter for binutils is defined [*]:

# Report for the whole binutils tagged builder set
generator_binutils = reporters.BuildSetStatusGenerator(
         mode=('change',), tags=['binutils'])
mn_binutils = reporters.MailNotifier(
        fromaddr="builder@sourceware.org",
        sendToInterestedUsers=True,
        extraRecipients=['binutils@sourceware.org'],
        generators=[generator_binutils])
c['services'].append(mn_binutils)

So the generator is for the whole buildset (all builders for a
particular source change) and sents one email for all builders with
the 'binutils' tag which have "changed" their build status. So it only
sents email when there are builders in the (binutils) buildset which
changed from succeeded to failed (or back). It doesn't sent emails for
every failed builder (if it was already failing before).

So if you want to have builders that don't trigger sending a message
then don't tag them with "binutils". You can also have a different
mode, only sent email for builds triggered by a particular named
scheduler or branches.

https://docs.buildbot.net/current/manual/configuration/report_generators/buildset.html

> > [...]
> > If so lets just pick one or more of the workers which seem like stable
> > distros/arches that should always build gdb:
> > https://builder.sourceware.org/buildbot/#/workers
> > [...]
> 
> I, um, kind of jumped the gun and set up a blanket native binutils-gdb
> testbot here ("fedrawhide-x86_64"), just to give it a go.  Other than
> bothersome outgoing notifications, it should run the full testsuites
> and collect all that data into bunsen.

Well, actions trump words. Especially since you added your own worker!
Thanks. Lets see how things work out.

Note that since you are interested gdb too you might want to add a
separate scheduler. One that triggers on the same fileset changes, but
also includes files under gdb, gdbserver, gdbsupport, gnulib,
readline... If this is what you and Luis want, then go for it.

But this is a "big builds" that generate lots of "data". And I am a
little afraid that is precisely why old buildbot CI efforts
failed. Dead by information overload.

I think the buildbot is more useful if we can (also) define "small"
(quick) builds that only report on immediately actionable results.
Build or test failures that need to be fixed asap.

Cheers,

Mark

[*] The builder configs are in a public git repo:
    https://sourceware.org/git/builder.git

    There is a README with some explation how thing should work and a
    SETUP file describing the setup. There is even a TODO file with
    ideas to make the builder even better. Patches welcome!


  reply	other threads:[~2022-04-25 22:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <YmZkKRO+yUHeFqV0@wildebeest.org>
2022-04-25 10:37 ` Luis Machado
2022-04-25 10:43   ` Frank Ch. Eigler
2022-04-25 12:16     ` Luis Machado
2022-04-25 12:30       ` Frank Ch. Eigler
2022-04-25 18:20       ` Mark Wielaard
2022-04-25 18:27         ` Frank Ch. Eigler
2022-04-25 22:11           ` Mark Wielaard [this message]
2022-04-26  3:33         ` Alan Modra
2022-04-26  6:22           ` Jan Beulich
2022-04-26 12:27             ` Nick Clifton
2022-04-26 13:49               ` Jan Beulich
2022-04-26 15:47                 ` H.J. Lu
2022-04-27  6:15                   ` Jan Beulich
2022-04-28 12:10                 ` Nick Clifton
2022-04-28 13:07                   ` Jan Beulich
2022-04-26 15:54           ` H.J. Lu
2022-04-26 23:33             ` Alan Modra
2022-04-27 18:32               ` [PATCH] x86: Disable 2 tests with large memory requirement H.J. Lu
2022-04-26  7:01         ` Adding binutils to the GNU Toolchain buildbot on sourceware Luis Machado
2022-04-26  9:40           ` Frank Ch. Eigler
2022-04-26 22:59             ` Mark Wielaard
2022-04-26 22:34           ` Mark Wielaard
2022-04-28 12:23             ` Luis Machado
2022-04-28 13:50               ` Frank Ch. Eigler
2022-04-28 13:53                 ` Luis Machado
2022-04-28 14:22                   ` Frank Ch. Eigler
2022-04-28 17:04                     ` Mark Wielaard
2022-04-28 14:48                   ` Mark Wielaard
2022-04-28 14:19               ` Mark Wielaard
2022-04-28 14:47                 ` Thomas Fitzsimmons
2022-04-28 16:28                   ` Mark Wielaard
2022-04-29 20:04                     ` gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware) Mark Wielaard
2022-05-01 19:44                       ` Mark Wielaard
2022-05-03 15:41                         ` Simon Marchi
2022-05-13  8:21                       ` Mark Wielaard
2022-04-28 17:50               ` Adding binutils to the GNU Toolchain buildbot on sourceware Nick Alcock
2022-04-29 17:54                 ` Mark Wielaard
2022-04-30  0:12                   ` Nick Alcock
2022-04-30 22:27                     ` Mark Wielaard
2022-05-03 12:48                       ` Nick Alcock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmccekNrHdyGG1Vt@wildebeest.org \
    --to=mark@klomp.org \
    --cc=binutils@sourceware.org \
    --cc=fche@elastic.org \
    --cc=gdb@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=overseers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).