From: Luis Machado <luis.machado@linaro.org>
To: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Cc: Luis Machado via Gdb <gdb@sourceware.org>
Subject: Re: [RFC] Proposal for hosting GDB CI builds
Date: Thu, 1 Jul 2021 10:10:50 -0300 [thread overview]
Message-ID: <b374a6c4-e74d-a9bd-c9c6-0405dd800fac@linaro.org> (raw)
In-Reply-To: <ydd8s2q1bns.fsf@CeBiTec.Uni-Bielefeld.DE>
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.
next prev parent reply other threads:[~2021-07-01 13:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-30 16:46 Luis Machado
2021-07-01 9:40 ` Rainer Orth
2021-07-01 11:48 ` Luis Machado
2021-07-01 12:06 ` Rainer Orth
2021-07-01 13:10 ` Luis Machado [this message]
2021-07-02 9:05 ` Rainer Orth
2021-07-01 11:37 ` Christophe LYON
2021-07-01 11:50 ` Luis Machado
2021-07-01 12:08 ` Rainer Orth
2021-07-20 15:21 ` Luis Machado
2021-07-23 20:17 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b374a6c4-e74d-a9bd-c9c6-0405dd800fac@linaro.org \
--to=luis.machado@linaro.org \
--cc=gdb@sourceware.org \
--cc=ro@CeBiTec.Uni-Bielefeld.DE \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).