1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-30 17:33:07 +00:00
os-autoinst-distri-fedora/tests/rpmostree_rebase.pm
Adam Williamson 12fa93bd27 Tweak ostree build and rebase for update tests to be more robust
We have had several problems where rebasing from one release to
another just doesn't work, and we have to work around it somehow.
Sometimes it's difficult or impossible to do. All we want to do
here is check the rebase mechanism itself; we don't actually want
to assert that you can rebase to any specific other release.

For update tests, we should be able to use a non-standard ref
name for the ostree we build, embed into the installer image,
and install. That should mean we can then rebase to the standard
ref name for the same release, which should be much safer than
trying to rebase to a different release. We can't do this for
the compose tests, but at least for update tests I'm hoping this
makes things more robust.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-11 16:00:59 -07:00

91 lines
3.0 KiB
Perl

use base "installedtest";
use strict;
use testapi;
use utils;
sub run {
my $self = shift;
$self->root_console(tty => 3);
if (get_var("ARCH") eq "aarch64") {
# this should stop audit messages screwing things up
assert_script_run "rpm-ostree kargs --append=audit=0";
script_run "systemctl reboot", 0;
boot_to_login_screen;
$self->root_console(tty => 3);
}
# list available branches
my $subv = lc(get_var("SUBVARIANT"));
my $remote = "fedora";
$remote = "fedora-iot" if ($subv eq "iot");
assert_script_run "ostree remote refs $remote";
# get current branch
my $current = script_output "rpm-ostree status -b | grep fedora";
my $arch = lc(get_var("ARCH"));
# decide target
my $rebase;
my $target;
if ($current =~ "iot") {
$rebase = $current =~ "stable" ? "devel" : "stable";
$target = "fedora/${rebase}/${arch}/iot";
}
elsif ($current =~ "silverblue") {
my $relnum = get_release_number;
$rebase = $relnum - 1;
# avoid rebasing from 37 to <37, bad stuff happens
# FIXME when 38 branches, we should change this to RELNUM+1
$rebase = "38" if ($relnum eq "37");
# on update tests, just rebase to the 'official' ref for the
# release, as opposed to the custom ref we used when building;
# this should be more reliable than a different release
$rebase = $relnum if (get_var("ADVISORY_OR_TASK"));
$rebase = "rawhide" if ($rebase eq get_var("RAWREL"));
$target = "fedora/${rebase}/${arch}/silverblue";
}
elsif ($current =~ "coreos") {
$rebase = $current =~ "stable" ? "testing" : "stable";
$target = "fedora/${arch}/coreos/${rebase}";
}
# rebase to the chosen target
validate_script_output "rpm-ostree rebase $target --bypass-driver", sub { m/systemctl reboot/ }, 300;
script_run "systemctl reboot", 0;
boot_to_login_screen;
$self->root_console(tty => 3);
# check booted branch to make sure successful rebase
validate_script_output "rpm-ostree status -b", sub { m/$target/ }, 300;
# rollback and reboot
if (get_var("ADVISORY") eq "FEDORA-2023-f6afa6f9e5") {
# FIXME: workaround for a very odd phenomenon with this update
# https://bodhi.fedoraproject.org/updates/FEDORA-2023-f6afa6f9e5#comment-2919613
# if that keeps happening after the update is stable we will
# have to do this for all affected releases
script_run "rpm-ostree rollback && systemctl reboot", 0;
boot_to_login_screen(timeout => 450);
}
else {
validate_script_output "rpm-ostree rollback", sub { m/systemctl reboot/ }, 300;
script_run "systemctl reboot", 0;
boot_to_login_screen;
}
$self->root_console(tty => 3);
# check to make sure rollback successful
validate_script_output "rpm-ostree status -b", sub { m/$current/ }, 300;
}
sub test_flags {
return {fatal => 1};
}
1;
# vim: set sw=4 et: