Hi, Adam Williamson <adamw...@fedoraproject.org> writes:
> On Tue, 2021-12-07 at 13:21 +0100, Miro Hrončok wrote: >> Hello QA, >> >> is there a way (even a hacky one) to run openQA tests (the ones that run on >> Bodhi updates of critpath packages) on an open Pull Request? > > Hey Miro! Right now there really isn't, I'm afraid. The least official > thing we can run the tests for right now is a scratch build, so you > need to at least turn the PR into a scratch build somehow. > > There's no public/self-serve way to schedule for a scratch build at the > moment; someone with admin/moderator access (so, usually, me) needs to > do it for you. > > If there is substantial interest I could look at implementing something > here...I would expect that some system or other (CI? Koschei?) must > surely have a way of turning pull requests into package builds already, > so I'd want to find that and build on it rather than reinventing it if > possible. > > The other stumbling block is that we still don't run these tests on > Rawhide, so if you want to test the PR in the context of the > rawhide/main branch, it would be more difficult (even just doing a one- > off, because the tests use pre-rolled disk images as a base, and we > don't build several of the needed images for Rawhide currently). > > That's something that could change, but it would be a fairly major > thing and might possibly require me to beg infra for more hardware or > finally find the time to see if we can run openQA tests In The Cloud. I > can provide more details on that whole area if you're interested... So, opensuse and suse do the following for the released distributions (e.g. opensuse Leap): each update gets put into a staging area in the build service, which rebuilds a subset of the distribution, creates the installation images and publishes repositories from the staging area. Then openqa is triggered for the staging area and a bot reports back. This is not exactly a test on a pull request though, because the actual pull request equivalent happens in a different place. It is more equivalent to testing a bodhi update or a side tag. What I could imagine would be the following: some CI (e.g. Zuul) builds an image from the pull request and publishes that image somewhere publicly accessible. Then Zuul would trigger an openqa job and set ISO_1_URL or HDD_1_URL to the published image, openqa then pulls these and runs all tests. It would however require that no repositories are accessed during the tests. And we'd also need some bot to report back an pagure, but that shouldn't be impossible either, as openqa publishes all test results via mqtt. And yes, that will require more hardware to run so many tests. Hope this helps, Dan > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://www.happyassassin.net > > _______________________________________________ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
