From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130809 invoked by alias); 29 Jul 2016 15:40:02 -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 130764 invoked by uid 89); 29 Jul 2016 15:40:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=indication, junior, Hx-languages-length:3188, squash X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 29 Jul 2016 15:39:51 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 167A78B13E; Fri, 29 Jul 2016 15:39:50 +0000 (UTC) Received: from localhost (unused-10-15-17-51.yyz.redhat.com [10.15.17.51]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6TFdnFu028288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jul 2016 11:39:49 -0400 From: Sergio Durigan Junior To: Antoine Tremblay Cc: GDB Patches Subject: Re: [GDB BuildBot] New "Try Server" References: <8760rpef2m.fsf@redhat.com> X-URL: http://blog.sergiodj.net Date: Fri, 29 Jul 2016 15:40:00 -0000 In-Reply-To: (Antoine Tremblay's message of "Fri, 29 Jul 2016 07:49:09 -0400") Message-ID: <87shuscv22.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00375.txt.bz2 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. > Also since the regressions are calculated from one build to the next > won't that possibly be a problem if let's say build 7 introduces a FAIL, > then build 3 has the same FAIL, but build 2 had a PASS ? We would then > miss a regression on a master commit. As explained above, we would still see the regression happening because the gdb.sum file is not touched (just read) on a try build. > Should we have separate try builders to avoid that? My initial thought was that, but having more builders will pollute the web interface (although there is probably a way to suppress them to be displayed), and will only create more repositories on the buildmaster. But if I had infinite resources, then yeah, more builders would probably make sense :-). > I'm also curious about what happens if you send it a series of patches, > will it squash them ? 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. > In any case thanks for working on this :) I'm sure it will be quite > useful. My pleasure! -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/