This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [GDB BuildBot] New "Try Server"
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, GDB Patches <gdb-patches at sourceware dot org>
- Date: Fri, 29 Jul 2016 12:55:47 -0400
- Subject: Re: [GDB BuildBot] New "Try Server"
- Authentication-results: sourceware.org; auth=none
- References: <8760rpef2m.fsf@redhat.com> <wwokpopwekay.fsf@ericsson.com> <87shuscv22.fsf@redhat.com>
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:
>>>
>>> <http://gdb-build.sergiodj.net/cgit>
>>
>> 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