search

CentOS-PaaS-SIG / ci-pipeline

There are many projects that are concentrated on CI for Atomic Openshift. This is focused on complete CI testing of all Atomic and Base Runtime components for a new Atomic deliverable that comes from Fedora sources.
GNU General Public License v3.0
23 stars 35 forks source link

virt-customize: do not inject any RPMs #686

Open ignatenkobrain opened 6 years ago

ignatenkobrain commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Leave decision of which packages to install to the job?

Exactly!

johnbieren commented 6 years ago

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

ignatenkobrain commented 6 years ago

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

johnbieren commented 6 years ago

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

ignatenkobrain commented 6 years ago

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

johnbieren commented 6 years ago

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 commented 6 years ago

@thrix ^^

thrix commented 6 years ago

@Andrei-Stepanov ^^ :)

thrix commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.