Re: GCC Buildbot

[Martin Liška <mliska at suse dot cz>]

On 09/25/2017 12:13 PM, Paulo Matos wrote:
> 
> 
> On 25/09/17 11:52, Martin Liška wrote:
>> Hi Paulo.
>>
>> Thank you for working on that! To be honest, I've been running local buildbot on
>> my desktop machine which does builds your buildbot instance can do (please see:
>> https://pasteboard.co/GLZ0vLMu.png):
>>
> 
> Hi Martin,
> 
> Thanks for sharing your builders. Looks like you've got a good setup going.
> 
> I have done the very basic only since it was my interest to understand
> if people would find it useful. I didn't want to waste my time building
> something people have no interest to use.

Sure, nice kick off.

> 
> It seems there is some interest so I am gathering some requirements in
> the GitHub issues of the project. One very important feature is
> visualization of results, so I am integrating support for data gathering
> in influxdb to display using grafana. I do not work full time on this,
> so it's going slowly but I should have a dashboard to show in the next
> couple of weeks.

Would be great, what exactly do you want to visualize? For me, even having green/red spots
works fine in order to quickly identify what builds are wrong.

> 
>> - doing time to time (once a week) sanitizer builds: ASAN, UBSAN and run test-suite
>> - doing profiled bootstrap, LTO bootstrap (yes, it has been broken for quite some time) and LTO profiled bootstrap
>> - building project with --enable-gather-detailed-mem-stats
>> - doing coverage --enable-coverage, running test-suite and uploading to a location: https://gcc.opensuse.org/gcc-lcov/
>> - similar for Doxygen: https://gcc.opensuse.org/gcc-doxygen/
>> - periodic building of some projects: Inkscape, GIMP, linux-kernel, Firefox - I do it with -O2, -O2+LTO, -O3, ...
>>   Would be definitely fine, but it takes some care to maintain compatible versions of a project and GCC compiler.
>>   Plus handling of dependencies of external libraries can be irritating.
>> - cross build for primary architectures
>>
>> That's list of what I have and can be inspiration for you. I can help if you want and we can find a reasonable resources
>> where this can be run.
>>
> 
> Thanks. That's great. As you can see from #9 in
> https://github.com/LinkiTools/gcc-buildbot/issues/9, most of the things
> I hope to be able to run in the CompileFarm unless, of course, unless
> people host a worker on their own hardware. Regarding your offer for
> resources. Are you offering to merge your config or hardware? Either
> would be great, however I expect your config to have to be ported to
> buildbot nine before merging.

Hopefully both. I'm attaching my config file (probably more for inspiration that a real use).
I'll ask my manager whether we can find a machine that can run more complex tests. I'll inform you.

> 
>> Apart from that, I fully agree with octoploid that http://toolchain.lug-owl.de/buildbot/ is duplicated effort which is running
>> on GCC compile farm machines and uses a shell scripts to utilize. I would prefer to integrate it to Buildbot and utilize same
>> GCC Farm machines for native builds.
>>
> 
> Octoploid? Is that a typo?
> I discussed that in the Cauldron with David was surprised to know that
> the buildbot you reference is actually not a buildbot implementation
> using the Python framework but a handwritten software. So, in that
> respect is not duplicated effort. It is duplicated effort if on the
> other hand, we try to test the same things. I will try to understand how
> to merge efforts to that buildbot.

Yes, duplication in way that it is (will be) same things. I'm adding author of the tool,
hopefully we can unify the effort (and resources of course).

Martin

> 
>> Another inspiration (for builds) can come from what LLVM folks do:
>> http://lab.llvm.org:8011/builders
>>
> 
> Thanks for the pointer. I at one point tried to read their
> configuration. However, found the one by gdb simpler and used it as a
> basis for what I have. I will look at their builders nonetheless to
> understand what they build and how long they take.> 
>> Anyway, it's good starting point what you did and I'm looking forward to more common use of the tool.
>> Martin
>>
> 
> Thanks,
>

Attachment: master.cfg
Description: Text document