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.