[RFC] Proposal for hosting GDB CI builds

[Rainer Orth]

Hi Luis,

>>>> 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.

understood.  You can achieve somethine similar when installing Solaris
zones using particular profiles.  IIUC that's what had been used for the
Solaris port of Docker.

>>> 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.

Exactly.  Besides, I've got good contacts to Solaris engineering in case
I cannot figure out what's wrong by myself.

>> 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.

Agreed.  I'll certainly try that once we get there.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University