From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 8E94E3858D28; Mon, 25 Apr 2022 22:11:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E94E3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0b.wildebeest.org [172.31.17.141]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 1CE75302BBED; Tue, 26 Apr 2022 00:11:06 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id 987272E8046D; Tue, 26 Apr 2022 00:11:06 +0200 (CEST) Date: Tue, 26 Apr 2022 00:11:06 +0200 From: Mark Wielaard To: "Frank Ch. Eigler" Cc: Luis Machado , Overseers mailing list , binutils@sourceware.org, "gdb@sourceware.org" Subject: Re: Adding binutils to the GNU Toolchain buildbot on sourceware Message-ID: References: <5c1f217a-109c-2973-6c69-abf412133dee@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2022 22:11:13 -0000 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!