[SSSD] [RFC] Add basic support for CI test execution

Lukas Slebodnik lslebodn at redhat.com
Fri Jun 13 14:50:54 UTC 2014


On (13/06/14 16:49), Nikolai Kondrashov wrote:
>On 06/13/2014 03:14 PM, Lukas Slebodnik wrote:
>>On (13/06/14 14:50), Nikolai Kondrashov wrote:
>>>On 06/13/2014 02:00 PM, Lukas Slebodnik wrote:
>>>>On (13/06/14 13:40), Nikolai Kondrashov wrote:
>>>However, the fact that someone (who has different situation) does something,
>>>doesn't mean that it's an efficient thing to do. Could you please provide the
>>>rationale for your solution, so we can compare benefits and drawbacks and make
>>>a rational decision? Perhaps I'm biased, or am missing something.
>>>
>>I wrote it few times. I do not want to maintain two different list of build
>>dependencies. The referential and only source should be spec files in contrib
>>directory. I already proposed few solutionswhich will solve  problem for you
>>     * yum-builddep
>>     * obtaining dependencies from src.rpm with rpm.
>
>I'm sorry, but "I do not want" doesn't count as a rationale, especially since
>there are other people maintaining the package as well. What are the benefits
>of your solution for everyone? What do we win with it?
>
>Also, as I stated before, extracting dependencies from the RPM is not the main
>problem. The main problem is unnecessary complexity.
I'm sorry but you should explain to me benefit of maintaining the same build
dependencies on two different places.

In near future, there will be bigger differences between rhel6, rhehl7 and
fedora. You will need to maintain very similar dependencies in CI for rhel6
and fedora22(alias new rawhide). We already maintain them in sssd.spec.

>>>>This discussion bring to my mind another test which is missing.
>>>>You should also test building sssd from src.rpm. Kevin Wright runs
>>>>nightly builds of sssd master on rhel6. It should be part of CI.
>>>
>>>Yes. I'll try adding that to the "DEBUG" build, "full" set, using the
>>>"prerelease-rpms" and "prerelease-srpm" targets on Red Hat distros.
>>>
>>I would prefer to rebuild src.rpm with mock. It will rebuild src.rpm in chroot
>>with minimal set of dependencies from spec file. I use it for testing very
>>often.
>>
>>$ mock --root epel-6-x86_64  --resultdir . --rebuild sssd-1.11.92-0.fc20.src.rpm
>>$ mock --root fedora-20-x86_64 --resultdir . --rebuild sssd-1.11.92-0.fc20.src.rpm
>>
>>https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds?rd=Extras/MockTricks
>>
>>You can create src.rpm without executing configure script
>>and thus without make srpm. (contrib/fedora/make_srpm.sh)
>
>CI runs configure anyway, so "make srpm" would be better as it's slightly more
>reliable compared to make_srpm.sh which duplicates substitution code.
>
You need to execute configrure for "make srpm"
thus you need to have installed all dependencies
and we are back to the problem with maintaining build depdendencies for fedora&rhel

make_srpm.sh is reliable. It is used by Kevin Wright to rebuild srpm
on rhel6 and he caught few problems in last months.

>Mock seems the right thing to do in general, but not on the CI server, since
>the latter already has builders with various distributions and installs
>dependencies itself. Using it there would duplicate the functionality and
>load to some extent and it wouldn't make sense to run it on each of the
>builders.
>
I proposed mock because it will not be difficult to integrate it. As you could
see, it is a simple command and configuration of mock is very easy.
With CI, you cannot guarantee minimal set of build dependencies.
On VM with CI, leftovers from previous builds can be installed and it can hide
some problems. Or do you want to start new clean VM every time?
It would be overkill from my POV.

mock and rpm are fedora/rhel specific. I am not sure if it works with opensuse.
They have Open Build Service. On the other side, we needn't test each
distribution in CI from beginning. Fedora, rhel, debian are good start.

>I would say that building directly on the builder distro will be good enough
>for a start. Later we can replace it with a separate script and a separate
>builder for running mock builds with various distros.
I am not against directly building sssd on distro. It is faster, because you
will need to compile sssd few times (scan-build, with gcc for valgrind and
others otions in future). Building with mock can be additional test and
it needn't be part of reduced test set.

BTW building src.rpm in mock is slow only on first time, because mock will
cache rpms in /var/cache/mock/<dist>-<arch>. And building packages in mock is
proven by time because it is used by koji for buiding every package
in fedora/epel.

>>>>You will be able to extract build dependencies from src.rpm with rpm command
>>>>and install dependencies with yum. (it will solve your problem with
>>>>yum-builddep)
>>>>     e.g. rpm -q -p --requires rpmbuild/SRPMS/sssd-1.11.92-0.fc20.src.rpm
>>>
>>>This doesn't produce output which can be used by yum. For example, yum doesn't
>>>know what to do with "rpmlib(CompressedFileNames)", or with "libdhash-devel >=
>>>0.4.2", which is a shame, really.
>>>
>>that isn't true
>>
>>[root at host ~]# yum install "libdhash-devel >= 0.4.2"
>>Loaded plugins: auto-update-debuginfo, langpacks
>>Package matching libdhash-devel-0.4.3-20.fc20.x86_64 already installed.
>>Checking for update.
>>Nothing to do
>>
>>[root at host ~]# yum install "pkgconfig(ini_config)"
>>Loaded plugins: auto-update-debuginfo, langpacks
>>Package matching libini_config-devel-1.0.0.1-20.fc20.x86_64 already installed.
>>Checking for update.
>>Nothing to do
>
>Hmm, somehow this didn't work for me when I tried, or perhaps I misinterpreted
>results of my tests, sorry.
>

I use 'yum install "pkgconfig(ini_config)"' when I don't remember name of
package and I am lazy to search for package with "yum provides */ini_config.pc"

You can use it also for installation of other packages. It is very usefull.
e.g.
  yum install "perl(IO::Handle)"
  yum install "perl(:MODULE_COMPAT_5.18.2)"
  yum install "python(abi) = 3.3"

LS



More information about the sssd-devel mailing list