virt-customize: do not inject any RPMs

[ignatenkobrain]

This would not work if there are conflicting subpackages. Also it's much better to leave decision of which packages to install to the job.

[johnbieren]

Leave decision of which packages to install to the job? So package foo is built in Koji. It creates 5 rpms. foo-bar.rpm, foo-baz.rpm, foo-one.rpm, foo-two.rpm, foo-three.rpm. How is this fully automated system supposed to know which rpms to install? How is the pipeline job supposed to know? Should it have a static list for every single package that exists so it knows when curl comes through, don't install curl minimal? I don't see any fix for this that can be written in an automated way that is better than trying to install whatever rpms get pulled down from the completed koji build.

[ignatenkobrain]

Leave decision of which packages to install to the job?

Exactly!

[johnbieren]

Job == Jenkins Pipeline. How is it supposed to know?

[ignatenkobrain]

@johnbieren just do not install any RPMs in virt-customize.sh

[johnbieren]

Then when will they be installed? They need to be installed to test them

[ignatenkobrain]

Playbook which runs from package-test.sh could install them.

[johnbieren]

Hmm interesting. That would have to be taken up with Miroslav's team, as that would be a change to standard-test-roles playbooks. If the installation was moved there, the check that the proper nvrs are installed would hopefully be moved inside as well.

[johnbieren]

@thrix ^^

[thrix]

@Andrei-Stepanov ^^ :)

[thrix]

the thing is, the staging of the packages to install is currently defined as a responsibility of the test system (the ci pipeline). Most packages which we have tests for are relying on the installation of the koji build. So we cannot just remove it. I believe the correct solution is to give @ignatenkobrain a solution to specify which packages to install (or blacklist). Or even, in the most extreme case, just do not install the packages at all and let the test handle it.

[thrix]

We should start defining a ci.yml file for these cases. this is just one of the stuff we will need to custumize. This file than should be used by the CI system to customize the test environment preparation etc.

[Andrei-Stepanov]

Playbook which runs from package-test.sh could install them.

Playbook is STR/STI.
Playbook doesn't not prepare test-environment.
STR takes test-environment as an input.

From: https://fedoraproject.org/wiki/CI/Standard_Test_Interface
Test environment: environment where actual test run takes place. Test has direct impact on test environment.

STI/STR tests test-environment.
Test-environment preparation is not part of STI/STR (playbook).
Test-environment preparation is out of scope STI/STR.