FrostyX / fedora-review-service

Fedora package reviews CI
9 stars 1 forks source link

Using `tmt` test backend to extend tests performed #51

Open LecrisUT opened 4 months ago

LecrisUT commented 4 months ago

The idea came when considering the need for installability in the review process. It would be nice to have a more extensible framework to add default checks like the rpmlint is done.

Currently there are rpminspect and rpmlint plans ^1 that can run on copr builds.

FrostyX commented 4 months ago

Hello @LecrisUT, thank you for the RFE.

I think I will need some additional context to fully understand this. Fedora Review Service is a very simple idea. It is only a middle-man between Bugzilla and Copr, it doesn't run (almost) any checks by itself. And Copr outsources all the checks to the fedora-review tool and just returns its results output.

I am not sure where among these pieces fits tmt. Should Fedora Review Service use tmt? Or should Copr?

Also, what will be the benefit? The fedora-review tool already runs rpmlint on the RPM packages. I don't know about the rpminspect.

LecrisUT commented 4 months ago

And Copr outsources all the checks to the fedora-review tool and just returns its results output.

Ack, forgot about that aspect.

Also, what will be the benefit?

The main issue I've had was with having some sort of installability test. On rust projects it is useful because dependency issues might not pop up until then. It's also helpful when a new package is meant to obsolete an older one.

I am not sure where among these pieces fits tmt

Hmm this is a though one then. tmt and testing-fatm can potentially give more navigable html results, but the only place to slot this in would be in the review tool. But then there's the balancing of resources to be considered if it's running within copr

Main reasoning for tmt is to outsource the maintenance of test definition to something more central, e.g. fedora-ci, where these tests are already being manage.