On Fri, 2023-03-03 at 18:37 +0100, Miro Hrončok wrote: > Hello, > I've noticed in > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-f34afe57a9 > https://bodhi.fedoraproject.org/updates/FEDORA-2023-a61dbc3c1d > https://bodhi.fedoraproject.org/updates/FEDORA-2023-a61dbc3c1d > > That the update is marked as critpath (which is probably correct because > python3-devel Requires it and many Python package BuildRequire it) and hence > the OpenQA tests run. However the probably unused in those tests, considering > it contains RPM macros. > > Unless the OpenQA tests actually rebuild everything involved with this package > (which I doubt, because it's not that slow) before running the tests, what is > the point of running them for this update? Should it not be in critpath? Or > should such tests only run if the produced package would be installed in the > test environment even when not explicitly installed? There is no point, but there may be nothing much we can do about it. I have been improving things in this area recently with a lot of work under the general heading "grouped critical path", but if you mouseover the critpath icon for the update, you'll see the package is in the core group, and the kde, gnome and server critical path groups (which means something explicitly listed in each of those groups ultimately depends on it). If something is in the core group, we kind of have to schedule all the openQA tests for it. Things in core could potentially break *anything*. It is an unavoidable hazard that, sometimes, via long dep chains, this results in us running the tests on things they don't really cover. Similarly, we have to run the GNOME tests for things in the GNOME critpath group, the KDE tests for things in the KDE critpath group, and the Server tests for the things in the Server critpath group. So even if we manage to get it out of @core , we would still have to run the KDE, GNOME and Server tests on it unless we could get it out of those groups too. So the question really is, what causes it to be in those groups? I suspect it's something in the dep chain of pyproject-srpm-macros , but at a quick glance I can't figure out what. If anyone has a good dep visualizer they can throw at the problem it'd help, I guess. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
