ea1c3bc
@@ -5,7 +5,6 @@
subject_type: koji_build
rules:
- !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
- - !PassingTestCaseRule {test_case_name: baseos-qe.koji-build.scratch-build.validation}
--- !Policy
product_versions:
- rhel-8
What did the baseos-qe.koji-build.scratch-build.validation rule do? What kind of scratch build did it perform?
https://github.com/fedora-ci/scratch-build-test
OK, if I understand that script then the idea is that when dwz is updated then it does a kernel build using the new dwz.
Don't we want that? The kernel does contain some programs that dwz can work on. It would be bad if that fails.
Rebuilding some package might be useful, but kernel is one of the worst choices for such a package, because dwz doesn't work on relocatable files (i.e. modules) and so doesn't do almost anything. So testing dwz by kernel rebuild which takes a long time is mostly wasted cycles. Better build some C++ package where dwz can be in better action. Though, at least currently rpm scripts ignore errors from dwz (dwz is applied as if it works and helps the debug info size, let's use it, otherwise keep the original), so one wouldn't test much either, unless e.g. the CI scripts then check the build.log files for dwz messages.
It's just an misconfiguration inherited from template of new CI gating workflow.
Pull-Request has been merged by mjw
OK, lets remove it then. Thanks for all the explanations.
