From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sYD5KK8cZ2IuigIAWB0awg (envelope-from ) for ; Mon, 25 Apr 2022 18:11:59 -0400 Received: by simark.ca (Postfix, from userid 112) id 9AD2F1E058; Mon, 25 Apr 2022 18:11:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0FB911E01D for ; Mon, 25 Apr 2022 18:11:59 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7D5E7385843E for ; Mon, 25 Apr 2022 22:11:58 +0000 (GMT) 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" 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-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: , Cc: "gdb@sourceware.org" , Overseers mailing list , binutils@sourceware.org Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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!