fedora-ci/installability-pipeline

Use RHEL not CentOS Stream for EPEL 8

Opened this issue · 5 comments

The EPEL 8 config uses CentOS Stream:

    "epel8": {
      "profile_name": "centos-stream-8",
      "compose": "CentOS-Stream-8"
    },

But CentOS Stream 8 went EOL on May 31, and now the repos seem to be inaccessible (see https://src.fedoraproject.org/rpms/glfw/pull-request/6 ). @nirik says it should use RHEL 8 as a base instead.

mini-tps does have RHEL 8 profiles, so we could change profile_name to e.g. rhel-8.10.0. I don't know what compose should be, though. It would also need updating quite regularly as new RHEL 8 minor versions appear; I don't know if mini-tps could grow a rhel-8-latest symlink, or something.

hum, possibly the mini-tps profiles won't work for Fedora CI, in which case we'd have an issue. maybe we can borrow the setup koji uses for EPEL builds? Kevin says "epel8 builds work by us syncing rhel8 and letting koji use that as an external repo. It's also not public."

another thing I notice about this: it doesn't look like the EPEL pipelines do anything to make EPEL itself available in the test context? Which would mean tests will fail falsely for any EPEL build that depends on anything else from EPEL...

I brought this general problem up in OSCI-3778. I requested to have installability checks run on EPEL Bodhi updates. It was asked if this could be done on CentOS Stream, and I advised against it. Besides the lifecycle difference that is noted here, it also gives us false failures and false successes. The idea came up about getting RHEL machines in Testing Farm for Bodhi updates, but didn't seem to go anywhere. The issue was eventually closed without resolution.

We're in the process of standing up EPEL 10, and uninstallable packages are already showing up. We actually can use CentOS Stream 10 to test these updates right now, thanks to the new EPEL 10 structure. We'll still eventually need to have RHEL 10 for checks as well, and the need for RHEL 9 and RHEL 8 never went away.

My long-term goal is that a failed Bodhi installability check will block the update from going to stable, or at the very least disable the autopush based on time/karma.

cc: @msrb @thrix @jankaluza

Note, installability is already known to have various issues which make it unsuitable for gating Fedora updates, without any EL-specific wrinkles. See at least https://pagure.io/fedora-ci/general/issue/448 .

Thanks for the reference to that other issue. I'm not aware of any packages in EPEL where certain combinations of subpackages from the same build are not installable together. Even if they do exist, they would be a tiny edge case. I would be quite happy with gated EPEL updates with an opt-opt mechanism for the edge cases.