On 16-06 python-urllib3 v. 1.26.5 was build in Koji. On PR against python-urllib3 the tmt tests of pipenv are run on Fedora CI. The update has brought fixes to make failing smoke2 pipenv test pass again. Triggered tests passed. pipenv, on install, pulls python-urllib3 as one of the runtime dependencies. So far so good.
smoke2
Later, I want to run pipenv's tests on an unrelated PR. I expect that python-urllib3 will be pulled in the latest available version which can be found in Koji repo as well.
This is where things start looking weird: the already-fixed smoke2 test fails again. Digging into test artifacts, I can find installed packages of this test run, which don't list python-urllib3 at all. Rerunning the tests on 21-06 doesn't have any effect, it seems like python-urllib3 is still run in the previous version. I'm fairly confident the tests should pass now (given they've passed on python-urllib3 update).
What I expect: pipenv's tests should pass during Fedora CI run. If they don't, I'd like to determine what version of python-urllib3 is used for the test run, and if not the latest, why is that? What can I do to help myself here? Is this a bug?
Thank you for all the help here.
I've added rpm -qa to the test script which revealed that indeed the obsolete version of python-urllib3 is being installed in this case.
rpm -qa
I have the same issue with pipenv CI. I've tried to update it but the CI seems to still use an obsolete version of python3-urllib3 even a newer and fixed version is already in rawhide repositories and I'm not able to reproduce the problem locally.
@mvadkert I think buildroot repo should be enabled in CI, do I remember it correctly?
yes, and it is. the current priority should be:
https://pagure.io/fedora-ci/general/issue/252#comment-737205
But seems there is some bug around checking if packages are really installed, not yet about that yet.
so it should be correctly set according to a runing system :(
[root@ip-172-31-17-161 ~]# grep priority /etc/yum.repos.d/* /etc/yum.repos.d/tag-repository.repo:priority=9 /etc/yum.repos.d/test-artifacts.repo:priority = 1
now ... where is the bug :(
@ksurma right, the problem here is that the package python3-urllib3 is in the default installation. We do not update to latest versions, the installation would just pull in the new version if there is a version requirement when installing the tested build. We update the compose each week, sometimes less. We would like to lower that to the day, but the issue would be still there. if you insist having latest package versions before testing, I would add a prepare steps that updates to the latest versions of the packages you expect to be updated, even if they are in the default install.
Metadata Update from @mvadkert: - Issue assigned to mvadkert
as for the package listing, this is what we will add:
package listing before installing anything -> should show the base installation rpms
package listing after artifact installation
@ksurma I hope that will help
Oh, this is baically https://pagure.io/fedora-ci/general/issue/20#comment-579574 again.
I think that packagers expect up to date packages automatically. Excepting them to copy-paste "dnf upgrade" to all tests is weird :/
@churchyard yeah ... I get it ...
so we can try to do dnf update as the first thing before running each test (for now just in rawhide), but I will also need to do restart because kernel :(
but I will also need to do restart because kernel :(
That did not occur to me :/
Updating just the user space might be a good compromise, but testing with up to date kernel is also nice (especially since Koji runs %checks with an old kernel).
%check
added playbook to install latest changes and restart if kernel updated. Let's see if it will fly .....
Base system is now updated before running the tests. Kernel is restarted if kernel was among updated pkgs.
http://artifacts.dev.testing-farm.io/79c0023e-d104-4dd9-abbf-338f1c681bfc/guest-setup-d8008514-6187-4b96-888d-8868f28642e3/guest-setup-output-pre-artifact-installation.txt
Metadata Update from @mvadkert: - Issue status updated to: Closed (was: Open)
@mvadkert, thanks for making the change. I like this solution and I'll monitor the behavior in our use cases.
Login to comment on this ticket.