Use Fedora instead of Ubuntu in our CI

[nwalfield]

Currently we use Ubuntu in CI, because that is one of GitHub's officially supported docker images. We should probably test on Fedora instead, as that is (currently) the main user of rpm-sequoia. And, at least a few tests are highly sensitive to the environment. See this issue, for instance.

[pmatilai]

This is of course up to you, side-quests like some randomly failing test when you're trying to cut a release are not exactly inspiring, been there :sweat_smile: But just FWIW, having rpm semi-regularly compile-tested on a non-Fedora distro does have non-zero value for us. So we don't mind at all if it turns up the occasional issue, such as that uid thing which revealed an rpm bug we didn't really know was there, although we had already just recently fixed it.

What I would prefer though is getting rpm-sequoia tests on 4.19.x because 4.18.x with its autotools and fakechroot-reliant test-suite is getting problematic. If you want, I can try submitting a PR for that.

[nwalfield]

This is of course up to you, side-quests like some randomly failing test when you're trying to cut a release are not exactly inspiring, been there 😅 But just FWIW, having rpm semi-regularly compile-tested on a non-Fedora distro does have non-zero value for us. So we don't mind at all if it turns up the occasional issue, such as that uid thing which revealed an rpm bug we didn't really know was there, although we had already just recently fixed it.

Given the great help I got debugging the recent issue, I don't mind. Nevertheless, wouldn't it make more sense to add such a job to rpm's CI?

What I would prefer though is getting rpm-sequoia tests on 4.19.x because 4.18.x with its autotools and fakechroot-reliant test-suite is getting problematic. If you want, I can try submitting a PR for that.

I've wanted to switch CI to 4.19, but I haven't found the time. If you have the bandwidth to do that, I'd be happy to receive a PR :).

When you say that 4.18 is getting problematic, does that mean that we don't have to worry about supporting 4.18 anymore? If so, we could remove some code from rpm-sequoia. For instance, pgpPrtPkts, and pgpNewDig were scheduled to be removed in 4.19, I noted. And, they are no longer mentioned in rpmpgp_sequoia.c.

[pmatilai]

Nevertheless, wouldn't it make more sense to add such a job to rpm's CI?

For ensuring it remains buildable sure, it's just that it doesn't seem worth burning all those cycles for each and every commit. It gets clunky when external dependencies move in different speeds etc.

I've wanted to switch CI to 4.19, but I haven't found the time. If you have the bandwidth to do that, I'd be happy to receive a PR :).

Ack.

When you say that 4.18 is getting problematic, does that mean that we don't have to worry about supporting 4.18 anymore?

4.18 will be on life-support until 4.20 final is released, so unless it starts getting in the way of things too much, I'd keep it around for the time being (the next 7-8 months or so until 4.20). Problematic was a poor choice of words, it's just the chasm between autotools+fakechroot and cmake+containers versions and grows bigger by the week and the older stuff becoming something you'd rather not touch. I'm sure you know the feeling :smile:

[dmnks]

Ack on the "keep using 4.18 for the time being" as Panu suggested. The reason being that we reworked the test-suite runtime in 4.19 and now use a fully containerized setup, which unfortunately requires a bit more work to integrate the test-suite with a local build of rpm-sequoia. Basically - just setting up the library paths won't suffice, we'll have to actually install rpm-sequoia into the test image.

This is a more general RFE for our test-suite, though. We would ideally allow for building any part of the whole stack locally and testing rpm against that, e.g. popt would be another such candidate. I've filed this in our repo as https://github.com/rpm-software-management/rpm/issues/2877 and will go from there. Once it's implemented, we can then think about bumping the RPM version in your CI to 4.19 or later.

[pmatilai]

Yep, I initially thought this would be a nice little Friday project. Well, swapping to cmake is, but it's the test-suite where things get complicated. With the "obvious" cmake conversion, it goes like this

• rpm-sequoia and rpm compiled
• rpm test-suite lauches, which goes on to download and install fedora, rebuild rpm in that setting (and against packaged rpm-sequoia) and then execute the tests, which is not quite what the intention of the ci was...
• or rather, it would if the last step succeeded

So yep, moving from 4.18 turns out to be a little more complicated than I initially thought...

[dmnks]

• rpm test-suite lauches, which goes on to download and install fedora, rebuild rpm in that setting (and against packaged rpm-sequoia) and then execute the tests, which is not quite what the intention of the ci was...

Yup, in CI "mode", the test-suite compiles RPM as part of the Dockerfile (i.e. in a container). If you run it locally, it uses the native build, however the test-suite itself still runs in a container in the end, so you've gotta get rpm-sequoia in there...

[pmatilai]

Yep, but we don't have Dockerfile.ubuntu to run it natively (which I started doing but lost it to matryoshkas) so... :smile:

[dmnks]

Looking at the CI yaml here, it actually shouldn't be that hard to adjust it even without us doing anything in RPM proper.

What you want is to extend our OCI test image with rpm-sequoia built and installed into the root filesystem and then spawn a privileged Podman/Docker container on top of it, with the rpmtests script as its process.

This is what we do in our CI. We have a wrapper script around the Podman/Docker commands but you might as well just run those commands directly, just with your image.

Now, this might sound like gibberish to you (I've spent way too much time in this rabbit hole :smile:) so don't worry. I'll help out with the migration as mentioned. I just need to think about it a bit more...

[dmnks]

Yep, but we don't have Dockerfile.ubuntu to run it natively (which I started doing but lost it to matryoshkas) so... 😄

Yup, having a base Dockerfile would probably be the first step, indeed :laughing:

Edit: Or just use ours as the base (like mentioned in the previous comment), which in turn is based on Fedora. Of course, sticking to Ubuntu might have its own benefits, like you said above, so it all depends.

[dmnks]

Oh, and apologies for the slightly off-topic brainstorming here. This ticket is meant to cover the Ubuntu -> Fedora change in CI, not the 4.18 -> 4.19+ move. That of course can be done independently of all the chatter here, since 4.18 is using the old test-suite setup, as mentioned.

[nwalfield]

Oh, and apologies for the slightly off-topic brainstorming here.

No worries. I've seen worse off-topic discussions :D.