Re: [RFC] Proposal for hosting GDB CI builds

[Luis Machado <luis.machado@linaro.org>]

On 7/1/21 9:06 AM, Rainer Orth wrote:
> Hi Luis,
> 
>>>> Linaro can take care of providing builders and build jobs for ARM. Other
>>>> architectures would be handled by their respective contributors. Those
>>>> contributors can write jobs and plug builders as needed.
>>> thanks for coming forward with this: this is very welcome, given how
>>> easy it is to miss build failures and other issues especially on
>>> not-so-common targets.
>>> However, is there any documentation on setting up new builders?  I've
>>> never dealt with Jenkins before, and from glimpsing over the docs some
>>> time ago when Jeff Law talked about extending this GCC builders to a
>>> wider range of architectures left me completely at a loss: the whole
>>> thing felt like a total moloch with an incredible range of abilities,
>>> but little to no guidance on how to start.  If the GDB CI wants to
>>> extend beyond a Linux-only range of targets, I believe considerable
>>> documentation is necessary to make this happen.
>>
>> I know the feeling. I've been there myself as Jenkins is indeed a very
>> flexible tool. And I don't, by any means, claim to be an expert on
>> dealing with it.
>>
>> Usually what I do is to peak at the documentation and at what others have
>> implemented. Then I work on extending/modifying things to my needs.
> 
> same here.  In the case of the GDB and LLVM buildbots there was some
> documentation to start from, although I'd still to figure several things
> out by myself.  Fortunately, the buildbot docs aren't that forbidding ;-)
> 
>> The GDB build job (currently running for aarch64/armhf/x86_64) I put
>> together is here:
>>
>> https://git.linaro.org/ci/job/configs.git/tree/tcwg-gdb.yaml
> 
> Fine, thanks.
> 
>> But I expect we will have to adjust this to make it a bit more generic so
>> other architectures can use it.
> 
> I'll certainly have look.  If nothing else, it's a start and way way
> easier than having to start from scratch.
> 
>>> Besides, I seem to have glimpsed from the Linaro instance that the
>>> builders use Docker.  Is this a requirement or just a convenience?  I'm
>>> asking because there's no current Docker port to Solaris (there used to
>>> be one based on zones, but it's no longer maintained) and the
>>> buildbot-based builders I'm running (for both LLVM and GDB) do fine
>>> without.
>>
>> That is a convenience so we can share hardware resources. It is possible to
>> use real hardware to run the jobs. One may need to adjust the
> 
> For my existing buildbots, I let them run inside Solaris zones (the
> equivalent of Linux containers) and could use ressource control features
> to provide additional containment (e.g. cpu, memory use) if need be.
> 

That's good. One other benefit of using docker images is the consistency 
between runs. You have control over the exact distro + set of packages 
that are installed in the image, so you have a better chance of being 
able to repeat a run.

>> configurations a bit (distro, packages etc), but a job can automate some
>> of that. Details about distros to use and packages to install still need to
>> be investigated/discussed.
> 
> In my case, I start from a configuration matching what I use for manual
> GDB builds, afterwards keeping the system up to date about once a
> months.  This makes the host somewhat a moving target, but the rate of
> chance hasn't ever caused problems.

I think that's reasonable. Regular updates shouldn't cause breakage to 
GDB. If they do, that's a sign that something was/got broken anyway.

> 
> Documenting the set of necessary packages is similar to what one needs
> for manual GDB builds, just a bit more formalized.

We maintain a set of required packages in a separate file. That file 
gets loaded and processed so we are sure all the dependencies are met. 
So coming up with a similar non-docker-based mechanism shouldn't be hard.