From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55479 invoked by alias); 29 Jul 2016 17:00:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 55464 invoked by uid 89); 29 Jul 2016 17:00:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=pollution, H*r:Symantec, Hx-spam-relays-external:!Symantec, H*RU:!Symantec X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 29 Jul 2016 17:00:13 +0000 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id AF.9C.02568.BCB8B975; Fri, 29 Jul 2016 19:00:59 +0200 (CEST) Received: from elxa4wqvvz1 (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 29 Jul 2016 12:55:48 -0400 References: <8760rpef2m.fsf@redhat.com> <87shuscv22.fsf@redhat.com> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Sergio Durigan Junior CC: Antoine Tremblay , GDB Patches Subject: Re: [GDB BuildBot] New "Try Server" In-Reply-To: <87shuscv22.fsf@redhat.com> Date: Fri, 29 Jul 2016 17:00:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00377.txt.bz2 Sergio Durigan Junior writes: > On Friday, July 29 2016, Antoine Tremblay wrote: > >> Sergio Durigan Junior writes: >> >>> Last, but not least, your try build will generate its own testsuite >>> logs, which will be recorded in that builder's git repository, available >>> at: >>> >>> >> >> Humm won't that "pollute" the builder results ? >> >> I mean, if the builder is testing commit 1 2 3 and that those are >> commits that were done on master but there's a try patch coming in >> between named say 7 and it has higher priority. >> >> You will then have 1 2 7 3 being tested. >> >> Then when we want to check the results of 1 2 3 won't it be confusing to >> see 7 there ? Will there be an indication that it's a try patch ? > > Yeah, that was my concern as well. I took extra care when recording the > results on the git repo. > > So, as you can see on the repositories for each builder I record the > following files: > > - baseline > - gdb.log > - gdb.sum > - previous_gdb.sum > > When a normal build is triggered, BuildBot will: > > - Copy the current gdb.sum to previous_gdb.sum > > - Perform the build > > - Upload the gdb.log file from the buildslave > > - Use the current gdb.sum to calculate the regressions against the new > gdb.sum (generated by the testsuite) > > - Update the current gdb.sum with the contents of the new gdb.sum > > - Save everything on the repo > > Now, when a try build is triggered, here's what will happen: > > - Perform the build > > - Upload the gdb.log file from the buildslave > > - Use the current gdb.sum to calculate the regressions against the new > gdb.sum (generated by the testsuite) > > - Update the current trybuild_gdb.sum with the contents of the new gdb.sum > > - Save everything on the repo > > So, as you can see, on a try build we don't mess with the files > necessary to calculate the regressions on a regular build. > Ha great :) that's a good way indeed and it avoids the builders pollution. > If you use the first method I explained (having a local branch and > invoking "buildbot try" without the "--diff" option), then it will > squash all your local commits into one patch. If you use the second > method ("--diff" option), then IIRC you can only send one patch. > OK. Worst case I guess one could script it to send a series without much effort or add it to its git rebase hook... Thanks, Antoine