From de2c44e7ae80d522f20b4beed0a149d86627e8d2 Mon Sep 17 00:00:00 2001 From: Adam Williamson Date: Wed, 11 Dec 2019 12:02:21 -0800 Subject: [PATCH] Work around Lmod bug in KDE update packages, with new mechanism It seems like the situation where we need to pull an update from updates-testing into all update tests to work around some known issue is going to keep happening. So instead of constantly adding and then entirely removing bespoke lines for each specific workaround, let's have a permanent mechanism for doing this: a hash with release numbers as keys, and arrayrefs of update IDs as values, and a block to call `bodhi updates download` on the appropriate array for the release under test. This way, to add or remove a workaround you just update the hash. If we're at a point where *no* workarounds are needed the %workarounds hash can be made entirely empty (it must exist, though) and the code will be a clean no-op. The actual workaround here pulls in Lmod updates I just sent out to work around this issue in one of the KDE update tests: https://openqa.fedoraproject.org/tests/497160#step/base_update_cli/11 there's some code in Lmod that gets sourced in bash profiles which breaks openQA's `validate_script_output` by blurping two lines of informational output into the output of the script. The update backports a change from upstream Lmod master that sends that informational output to stderr instead of stdout. Signed-off-by: Adam Williamson --- lib/utils.pm | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/lib/utils.pm b/lib/utils.pm index 3ee19f2a..4f2c41b9 100644 --- a/lib/utils.pm +++ b/lib/utils.pm @@ -437,6 +437,7 @@ sub _repo_setup_updates { # Appropriate repo setup steps for testing a Bodhi update # Check if we already ran, bail if so return unless script_run "test -f /etc/yum.repos.d/advisory.repo"; + my $version = get_var("VERSION"); repos_mirrorlist(); if (get_var("DEVELOPMENT")) { # Disable updates-testing so other bad updates don't break us @@ -504,13 +505,30 @@ sub _repo_setup_updates { assert_script_run 'rpm -qp *.rpm --qf "%{NAME} " > /var/log/updatepkgnames.txt'; upload_logs "/var/log/updatepkgnames.txt"; + # we periodically need to pull an update from updates-testing in + # to fix some bug or other. so, here's an organized way to do it. + # we do this here so the workaround packages are in the repo data + # but *not* in the package lists generated above (those should + # only include packages from the update under test). we'll define + # a hash of releases and update IDs. if no workarounds are needed + # for any release, the hash can be empty and this will do nothing + my %workarounds = ( + "30" => ['FEDORA-2019-9ff3036c0a'], + "31" => ['FEDORA-2019-6f121fa8a0'] + ); + # then we'll download each update for our release: + my $advisories = $workarounds{$version}; + foreach my $advisory (@$advisories) { + assert_script_run "bodhi updates download --updateid=$advisory", 180; + } + # create the repo metadata assert_script_run "createrepo ."; # write a repo config file, unless this is the support_server test # and it is running on a different release than the update is for # (in this case we need the repo to exist but do not want to use # it on the actual support_server system) - unless (get_var("TEST") eq "support_server" && get_var("VERSION") ne get_var("CURRREL")) { + unless (get_var("TEST") eq "support_server" && $version ne get_var("CURRREL")) { assert_script_run 'printf "[advisory]\nname=Advisory repo\nbaseurl=file:///opt/update_repo\nenabled=1\nmetadata_expire=3600\ngpgcheck=0" > /etc/yum.repos.d/advisory.repo'; # run an update now (except for upgrade tests) script_run "dnf -y update", 900 unless (get_var("UPGRADE"));