Re: [RFC] Proposal for hosting GDB CI builds

Luis Machado via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.