Set-up Buildbot for GDC

Iain Buclaw via D.gnu d.gnu at puremagic.com
Tue Jul 4 15:45:45 PDT 2017


On 4 July 2017 at 23:05, Johannes Pfau via D.gnu <d.gnu at puremagic.com> wrote:
> Am Tue, 4 Jul 2017 20:42:52 +0200
> schrieb "Iain Buclaw via D.gnu" <d.gnu at puremagic.com>:
>
>>
>> How do these look?
>>
>> https://www.scaleway.com/armv8-cloud-servers/
>>
>> They also have ARMv7's too, I'm currently paying around 18€ a month
>> for the current linode box - 50G SSD, 4G memory, 2x cores.  For the
>> same price, could order the following kit for use as build workers.
>>
>> ARMv8: 50G SSD, 2G memory, 4x cores.  (aarch64 native)
>> ARMv7: 50G SSD, 2G memory, 4x cores.  (arm native)
>> x86_64: 100G SSD, 4G memory, 4x cores. (all cross compilers)
>
> The ARMs look good. I'm not sure about the X86_64: The 'VPS' are
> 'shared' but I haven't found any information what exactly they share
> (shared cores?). Additionally some 2016 reports say the VPS use
> Intel Atom cores and only the more expensive 'Bare Metal' plans use Xeon
> Cores. I haven't found any official information on the homepage though
> so we might have to ask or just try and check available CPU
> resources / build speed.
>

Well, the linode is running on a shared server as well (it's been
given 2 cores of a 12 core Xeon), so there's not much difference
there.  It seems that scaleway use specifically Avotons for their
low-end bare metal servers  (I did a quick look up for comparison:
http://ark.intel.com/compare/81908,77982).

I guess for the cross compilers, speed doesn't really bother me all
that much.  I'll probably just leave them to build master only anyway,
I don't see it necessary to have instant feedback from PRs with them,
an FYI for a recent change breaking something is enough - remember,
there are 17 configurations to test! (though I turned off half of them
due to lack of disk space).

For native builds, having a policy of must never break seems more reasonable.


>>
>> Yep, as this is dockerized, anyone can build + debug locally.  This
>> the patches should be fixed asap.  Also, if you look at the runtests
>> (skipping over the unresolved bits), you'll see that a few of them
>> ICE.  I've noticed this for aarch64, maybe others do the same.  This
>> is another thing that should be investigated and fixed.
>>
>> In other words, I would like to get all of them green, but only have
>> so much time. I better start by filtering out the noise first. :-)
>
> I'll try to setup a local builder for debugging later this week or next
> weekend and see if I can reduce some bugs.
>

I hope that it should be super easy - I used docker 17.06 and
docker-compose 1.8.  Should just be `docker-compose up worker-cross`
to fire up the build environment.  :-)


>> > BTW: Do you know if there's any way to cluster builds by branch on
>> > the buildbot main page? I haven't gotten that far in the docs
>> > yet ;-)
>>
>> Doesn't look like it.
>>
>> https://github.com/buildbot/buildbot/blob/0d44f0344ff82b707d02c75871df23c5f6b9cb8f/www/base/src/app/home/home.tpl.jade#L18-L24
>
> OK, then this is something to look into (a lot) later. I guess buildbot
> should allow setting up custom sub pages so there's likely some way to
> implement a per-branch overview.
>

I have a quick look to see if gdb or anyone else does this - answer,
it seems like they don't, it's just bundled in together.

https://gdb-build.sergiodj.net/grid
http://buildbot.python.org/all/grid
http://buildbot.nektar.info/grid

What you see are the build results for the last X changes,
irrespective of branch.

Regards,
Iain.



More information about the D.gnu mailing list