Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
Re: [opensuse-packaging] Non-blocking %check
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:

%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 \
&& ...

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()"

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups