[PATCH] rhel10-x86_64: add systemtap builder

[Serhei Makarov]

On Thu, Feb 20, 2025, at 3:30 PM, Mark Wielaard wrote:
> It would also be good to explain on list what this "rhel10" exactly
> is. I don't believe others can easily replicate it (or is it really
> c10s?)
Yeah, it's worth explaining a lot more. + raising an question or two.

On builder.sourceware.org there are two rows 'stap' and 'systemtap', referring to different buildbots.

'systemtap' is systemtap builds on a public buildbot machine, and those do not run the testsuite (which require kernel access and include tests beyond the default safety settings that would stress the stability of a shared system). So that gives very limited data.

'stap' is a set of *separate* builders, on a machine internal to Red Hat, which run the full systemtap testsuite in a virtualized environment. This includes the RHEL vms (currently RHEL8,9,10; actual RHEL as built by Red Hat), as well as CentOS Stream. We want to keep running our tests on RHEL, so if those vms aren't appropriate to list on builder.sourceware.org I would probably (a) keep running the RHEL VMs but feed results to a non-public bunsen instance and (b) replace the VMs feeding results to builder.sourceware.org with almalinux as suggested. For the other distros covered by the 'stap' VMs (Fedora and CentOS) I'm planning to open up the scripting that *creates* those buildbots, which would allow a similar environment to be quickly re-created. But the actual VMs aren't in a place that we could open up for direct access by the public.

Would it be worth renaming either 'stap' or 'systemtap' in a way that makes the distinction more obvious?

> I would recommend using alma linux for public workers so others can
> more easily replicate such a setup. I never could get a straight
> answer from Red Hat how to setup a RHEL buildbot CI for (shared)
> public use.
AIUI I don't think publishing test results from a non-public-accessible RHEL system is a problem for Red Hat, so long as the relevant RHEL version has been announced. It's purely a question of whether hosting those results is within the mission scope of sourceware or not, or if you only want results from public buildbots.

There's also a question of using bunsen results to collect test data on other architectures from only intermittently-available hardware, rather than a permanent buildbot. I tried to do this with the older bunsen prototype, before we moved the system to sourceware. Here I'm not sure whether it's appropriate to do that with sourceware resources or with a separate bunsen instance.

-- 
All the best,
    Serhei
    http://serhei.io