On Thursday 20 April 2017, Bernhard Voelker wrote:
On 04/20/2017 05:08 AM, Todd Rme wrote:
There has been some work and advice recently about improving the parallelization of project builds. However, one issue that occurred to me is that a lot of time can be spent running the %check scriptlet that shouldn't have any impact on the final RPMs.
My idea was that perhaps the RPM could be used for building packages that depend on it while the %check scriptlet is running. If the %check succeeds, then everything continues as normal. If not, then builds that depend on it are canceled and RPMs that depend on it are invalidated before being published.
I understand that this is a big change. In addition to needed big changes in how OSC works, this would also require a fundamental change in the %check macro. It would mean that things that happen during the %check scriptlet would no longer have any impact on the final RPMs. Personally I think this is a feature rather than a bug, I always thought it was strange that tests are allowed to change the package, but it is a big behavior change.
I am not sure this is worth the effort to implement or worth breaking existing RPM semantics. But if we are having a problem with the builds not being as parallel as they could be, this might be something at least to consider.
I'm not sure to which discussion you refer to (as you didn't point to it). I can only tell how it is done for the coreutils package [1] where the full check (`make check-very-expensive`) may run between ~15min and ~1.5h depending on the architecture. Without the checks, the package is built in ~3-15min. There's a 2nd spec file 'coreutils-testsuite.spec' which is generated from the regular 'coreutils.spec', and the %check section is only used by that secondary package:
%check %if "%{name}" == "coreutils-testsuite" ... # Avoid parallel make, because otherwise some timeout based tests like # rm/ext3-perf may fail due to high CPU or IO load. make check-very-expensive \ && ... %endif
Does this idea go into the direction you're thinking?
This is a nice idea but it has a few drawbacks: 1.A bad coreutils-testsuite does not seem to prevent automatically that the coreutils package would be released to the users. 2.coreutils-testsuite is not testing the *same* binaries which we install finally in the distro. Bugs or inconsistencies in OSB or rpm could cause that "coreutils" builds broken binaries but "coreutils-testsuite" looks ok. What I would really like is that project's like coreutils would have a "make check*" target which runs tests against the installed coreutils. Similar to some of our python packages, users could even test their final installation, like python -c "import numpy; numpy.test()" cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org