#788 fedora-obsolete-packages updates should be OpenQA tested/gated
Opened 3 months ago by churchyard. Modified 3 months ago

Hello.

I believe Bodhi updates for fedora-obsolete-packages should be treated as critical path updates. The package is quite critical and dangerous: it can accidentally Obsolete something that's needed and not retired.

I'd like the OpenQA gating tests to run/gate when fedora-obsolete-packages is updated.

However, I don't know if we can add the package to any critical path groups in comps -- after all, the package is not installable. This might also break assumptions from OpenQA tests.

E.g. the fedora-ci.koji-build.installability.functional test fails every time with this package.

Please help me accomplish my goal. Thanks


I can allowlist it for testing (there's a mechanism for that), but then it'd need a per-package gating policy to be gated on the results.

I don't think trying to test it would break openQA, but it's possible it wouldn't fully test the results of actually landing the update. The way we test updates in openQA is that we test on a system with the default repos enabled - so 'rawhide' for Rawhide, 'fedora' and 'updates' for stable releases and Branched - and also the buildroot repo for Rawhide. Then we create a local repo with the packages from the update in it, and enable that also.

This means that whatever packages are in the standard repos are always available to package managers in the SUT. We don't really have a mechanism where we can 'overlay' the packages from the update onto the standard repos so they look like they would if the update had actually landed (I wish we could). We do sometimes get differing behaviour in tests because of this. I can imagine that may be the case for this package too. dnf would know it has a repo (or two repos, in the case of Rawhide) with all the packages in it, and a package in another repo which says it obsoletes some of those packages; we'd be testing what happens in that situation.

I don't think adding f-o-p to critpath ought to break anything, if we decided to go that route. The critpath groups aren't really meant to be installed, they really only exist as inputs to the critpath generation script. But it's questionable whether it's really "correct".

Metadata Update from @adamwill:
- Issue assigned to adamwill

3 months ago

Log in to comment on this ticket.

Metadata