Are rpm tests in Zuul CI and t_functional from a clean VM?

Our Neighbors CentOS
1

I ask that question because I had one scenario where a package version (it was a third-party one) did install fine when done for the first time, but caused catastrophic issues when updating. Bugs in the rpm pre* or post* scripts. Basically, wondering about scope of the rpm tests in Zuul CI and t_functional.

Thank you!

2
  1. On the Zuul side, which runs on every merge request, we build a temporary rpm in mock on x86 architecture and then we may run additional tmt tests from the dist-git of the package, if they are available in the repo.

Normally these dist git tests run on a certain previously published image (could be a week old) and then install/update the package in test to the version we have built.

  1. I am not quite familiar with t_functional, but It seem to have a full upgrade test: Tree - centos/t_functional - CentOS Git server

We should check if it runs in the current setup.

But there are additional tests running on the RHEL side of the pipeline. Zuul doesn’t have access to them, but CentOS package should not go through the gate if its RHEL twin doesn’t pass them. And in that RHEL part of the testing we have a generic installability test, which tests that package update can be installed, uninstalled, upgraded and downgraded.

I would expect failure in pre/post scripts to be caught by something of the above. Maybe send me the link to the issue, so we can have some retrospective and check how it slipped through?

3

It was actually a third party package, specifically gitlab-ce. Zuul CI for third party packages in the new Integration SIG may be a good place for stuff like this.

Thank you @bookwar