This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Buildbot
- From: Paulo Matos <pmatos@linki.tools>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 21 Sep 2017 22:37:12 +0200
- Subject: Re: GCC Buildbot
- Authentication-results: sourceware.org; auth=none
- References: <fe9f8738-9edd-69a9-0161-6f8b24efdaa3@linki.tools> <20170920230135.GU8421@gate.crashing.org>
On 21/09/17 01:01, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Sep 20, 2017 at 05:01:55PM +0200, Paulo Matos wrote:
>> This mail's intention is to gauge the interest of having a buildbot for
>> GCC.
>
> +1. Or no, +100.
>
>> - which machines we can use as workers: we certainly need more worker
>> (previously known as slave) machines to test GCC in different
>> archs/configurations;
>
> I think this would use too much resources (essentially the full machines)
> for the GCC Compile Farm. If you can dial it down so it only uses a
> small portion of the machines, we can set up slaves there, at least on
> the more unusual architectures. But then it may become too slow to be
> useful.
>
We can certainly decide what builds on workers in the compile farm and
what doesn't. We can also decide what type of build we want. A full
bootstrap, all languages etc. I still have to look at that. Not sure how
to access the compile farm or who has access to them.
>> - what kind of build configurations do we need and what they should do:
>> for example, do we want to build gcc standalone against system (the one
>> installed in the worker) binutils, glibc, etc or do we want a builder to
>> bootstrap everything?
>
> Bootstrap is painfully slow, but it catches many more problems.
>
Could possibly do that on a schedule instead.
>> - We are building gcc for C, C++, ObjC (Which is the default). Shall we
>> add more languages to the mix?
>
> I'd add Fortran, it tends to find problems (possibly because it has much
> bigger tests than most C/C++ tests are). But all extra testing uses
> disproportionally more resources... Find a sweet spot :-) You probably
> should start with as little as possible, or perhaps do bigger configs
> every tenth build, or something like that.
>
Sounds like a good idea.
>> - the gdb buildbot has a feature I have disabled (the TRY scheduler)
>> which allows people to submit patches to the buildbot, buildbot patches
>> the current svn version, builds and tests that. Would we want something
>> like this?
>
> This is very useful, but should be mostly separate... There are of course
> the security considerations, but also this really needs clean builds every
> time, and perhaps even bootstraps.
>
There could be two types of try schedulers, one for full bootstraps and
one just for GCC. Security wise we could always containerize.
>> - buildbot can notify people if the build fails or if there's a test
>> regression. Notification can be sent to IRC and email for example. What
>> would people prefer to have as the settings for notifications?
>
> Just try it! IRC is most useful I think, at least for now. But try
> whatever seems useful, if there are too many complaints you can always
> turn it off again ;-)
>
> Thank you for working on this.
>
Thanks for all the comments. I will add the initial notifications into
IRC and see how people react.
--
Paulo Matos