This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC Buildbot



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]