Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
use base "installedtest";
|
|
|
|
use strict;
|
|
|
|
use testapi;
|
|
|
|
use utils;
|
|
|
|
|
|
|
|
sub run {
|
|
|
|
my $self = shift;
|
|
|
|
my $version = get_var("VERSION");
|
|
|
|
my $currrel = get_var("CURRREL");
|
|
|
|
my $rawrel = get_var("RAWREL");
|
|
|
|
my $repo = $version eq $rawrel ? "fedora-rawhide.repo" : "fedora.repo";
|
|
|
|
my $branch;
|
|
|
|
my $releasever;
|
|
|
|
if ($version eq $rawrel) {
|
|
|
|
$branch = "main";
|
|
|
|
$releasever = "Rawhide";
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
$branch = "f${version}";
|
|
|
|
$releasever = $version;
|
|
|
|
}
|
|
|
|
my $advortask = get_var("ADVISORY_OR_TASK");
|
|
|
|
my $arch = get_var("ARCH");
|
|
|
|
my $subv = get_var("SUBVARIANT");
|
|
|
|
my $lcsubv = lc($subv);
|
Revert to having tests, not the scheduler, download packages (#108)
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-05 19:41:50 +00:00
|
|
|
my $tag = get_var("TAG");
|
2022-12-03 20:36:52 +00:00
|
|
|
# mount our nice big empty scratch disk as /var/tmp
|
|
|
|
assert_script_run "rm -rf /var/tmp/*";
|
|
|
|
assert_script_run "echo 'type=83' | sfdisk /dev/vdc";
|
|
|
|
assert_script_run "mkfs.ext4 /dev/vdc1";
|
|
|
|
assert_script_run "echo '/dev/vdc1 /var/tmp ext4 defaults 1 2' >> /etc/fstab";
|
|
|
|
assert_script_run "mount /var/tmp";
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
assert_script_run "cd /";
|
|
|
|
# usually a good idea for this kinda thing
|
|
|
|
assert_script_run "setenforce Permissive";
|
|
|
|
# install the tools we need
|
2023-07-19 19:51:31 +00:00
|
|
|
assert_script_run "dnf -y install git lorax flatpak ostree rpm-ostree dbus-daemon moreutils", 300;
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
# now check out workstation-ostree-config
|
|
|
|
assert_script_run 'git clone https://pagure.io/workstation-ostree-config.git';
|
|
|
|
assert_script_run 'pushd workstation-ostree-config';
|
|
|
|
assert_script_run "git checkout ${branch}";
|
2022-12-10 17:25:29 +00:00
|
|
|
# now copy the advisory, workaround repo and koji-rawhide config files
|
Revert to having tests, not the scheduler, download packages (#108)
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-05 19:41:50 +00:00
|
|
|
assert_script_run 'cp /etc/yum.repos.d/workarounds.repo .';
|
2022-12-10 17:25:29 +00:00
|
|
|
assert_script_run 'cp /etc/yum.repos.d/koji-rawhide.repo .' if ($version eq $rawrel);
|
Revert to having tests, not the scheduler, download packages (#108)
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-05 19:41:50 +00:00
|
|
|
assert_script_run 'cp /etc/yum.repos.d/advisory.repo .' unless ($tag);
|
|
|
|
assert_script_run 'cp /etc/yum.repos.d/openqa-testtag.repo .' if ($tag);
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
# and add them to the config file
|
2023-07-04 20:13:15 +00:00
|
|
|
my $repl = 'repos:';
|
Revert to having tests, not the scheduler, download packages (#108)
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-05 19:41:50 +00:00
|
|
|
$repl .= '\n - workarounds';
|
2022-12-10 17:25:29 +00:00
|
|
|
$repl .= '\n - koji-rawhide' if ($version eq $rawrel);
|
Revert to having tests, not the scheduler, download packages (#108)
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-05 19:41:50 +00:00
|
|
|
$repl .= '\n - advisory' unless ($tag);
|
|
|
|
$repl .= '\n - openqa-testtag' if ($tag);
|
2022-12-10 17:25:29 +00:00
|
|
|
assert_script_run 'sed -i -e "s,repos:,' . $repl . ',g" fedora-' . $lcsubv . '.yaml';
|
2023-06-10 23:00:21 +00:00
|
|
|
# change the ref name to a custom one (so we can test rebasing to
|
|
|
|
# the 'normal' ref later)
|
|
|
|
assert_script_run 'sed -i -e "s,ref: fedora/,ref: fedora-openqa/,g" fedora-' . $lcsubv . '.yaml';
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
# upload the config so we can check it
|
|
|
|
upload_logs "fedora-$lcsubv.yaml";
|
|
|
|
assert_script_run 'popd';
|
|
|
|
# now make the ostree repo
|
2022-12-03 20:36:52 +00:00
|
|
|
assert_script_run "mkdir -p /var/tmp/ostree";
|
|
|
|
assert_script_run "ostree --repo=/var/tmp/ostree/repo init --mode=archive";
|
2022-12-06 21:29:16 +00:00
|
|
|
# need this to make the pipeline in the next command fail when
|
|
|
|
# rpm-ostree fails. note: this is a bashism
|
|
|
|
assert_script_run "set -o pipefail";
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
# PULL SOME LEVERS! PULL SOME LEVERS!
|
|
|
|
# This shadows pungi/ostree/tree.py
|
|
|
|
# Difference from releng: we don't pass --write-commitid-to as it
|
|
|
|
# disables updating the ref with the new commit, and we *do* want
|
|
|
|
# to do that. pungi updates the ref itself, I don't want to copy
|
|
|
|
# all that work in here
|
2023-07-27 19:26:23 +00:00
|
|
|
# we use --unified-core on F39+ as that's where it was turned on
|
|
|
|
# in prod
|
|
|
|
my $ucarg = "";
|
|
|
|
$ucarg = "--unified-core " if ($version > 38);
|
|
|
|
assert_script_run "rpm-ostree compose tree ${ucarg}--repo=/var/tmp/ostree/repo/ --add-metadata-string=version=${advortask} --force-nocache /workstation-ostree-config/fedora-$lcsubv.yaml |& ts '" . '[%Y-%m-%d %H:%M:%S]' . "' | tee /tmp/ostree.log", 4500;
|
2022-12-06 21:29:16 +00:00
|
|
|
assert_script_run "set +o pipefail";
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
upload_logs "/tmp/ostree.log";
|
|
|
|
# check out the ostree installer lorax templates
|
|
|
|
assert_script_run 'cd /';
|
|
|
|
assert_script_run 'git clone https://pagure.io/fedora-lorax-templates.git';
|
|
|
|
# also check out pungi-fedora and use our script to build part of
|
|
|
|
# the lorax command
|
|
|
|
assert_script_run 'git clone https://pagure.io/pungi-fedora.git';
|
|
|
|
assert_script_run 'cd pungi-fedora/';
|
|
|
|
assert_script_run "git checkout ${branch}";
|
2023-08-10 22:13:04 +00:00
|
|
|
assert_script_run 'curl --retry-delay 10 --max-time 30 --retry 5 -o ostree-parse-pungi.py https://pagure.io/fedora-qa/os-autoinst-distri-fedora/raw/main/f/ostree-parse-pungi.py', timeout => 180;
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
my $loraxargs = script_output "python3 ostree-parse-pungi.py $lcsubv $arch";
|
|
|
|
|
|
|
|
# this 'temporary file cleanup' thing can actually wipe bits of
|
|
|
|
# the lorax install root while lorax is still running...
|
|
|
|
assert_script_run "systemctl stop systemd-tmpfiles-clean.timer";
|
|
|
|
# create the installer ISO
|
|
|
|
assert_script_run "mkdir -p /var/tmp/imgbuild";
|
|
|
|
assert_script_run "cd /var/tmp/imgbuild";
|
|
|
|
|
|
|
|
my $cmd = "lorax -p Fedora -v ${version} -r ${version} --repo=/etc/yum.repos.d/${repo} --variant=${subv} --nomacboot --buildarch=${arch} --volid=F-${subv}-ostree-${arch}-oqa --logfile=./lorax.log ${loraxargs}";
|
|
|
|
unless ($version > $currrel) {
|
|
|
|
$cmd .= " --isfinal --repo=/etc/yum.repos.d/fedora-updates.repo";
|
|
|
|
}
|
Revert to having tests, not the scheduler, download packages (#108)
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-05 19:41:50 +00:00
|
|
|
$cmd .= " --repo=/etc/yum.repos.d/workarounds.repo";
|
2023-03-18 15:37:01 +00:00
|
|
|
$cmd .= " --repo=/etc/yum.repos.d/koji-rawhide.repo" if ($version eq $rawrel);
|
Revert to having tests, not the scheduler, download packages (#108)
This effectively reverts 97618193 - but had to be done manually
and adjusted to maintain support for testing side tags and for
testing multiple tasks, since those features were added since
the update ISO change.
The 'scheduler injects ISOs of packages into the tests' approach
was intended to speed things up, especially for large updates,
and it did, but it had a few drawbacks. It means restarting
older tests from the web UI doesn't work as the ISOs get garbage
collected (you have to re-schedule in this case). And it has the
rather large problem that you can now only schedule tests from
the openQA server (or at least a machine with the openQA asset
share mounted), because the package download and ISO creation
just happen wherever the scheduler is running and assume that
the openQA asset share that will be used by the tests is at
/var/lib/openqa/share in that filesystem.
That's too big of a drawback to continue with this approach, IMO,
so this reverts back to the old way of doing things, with a bit
of refactoring to clean up the flow a little, and with support
for testing side tags and multiple tasks maintained.
As a follow-up I'm going to see if I can replace
_download_packages with a much more efficient downloader script
to mitigate the time this process takes on each test, especially
for large updates.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-05 19:41:50 +00:00
|
|
|
$cmd .= " --repo=/etc/yum.repos.d/advisory.repo" unless ($tag);
|
|
|
|
$cmd .= " --repo=/etc/yum.repos.d/openqa-testtag.repo" if ($tag);
|
2023-03-18 15:37:01 +00:00
|
|
|
$cmd .= " ./results";
|
2023-02-17 04:36:14 +00:00
|
|
|
assert_script_run $cmd, 7000;
|
Add tests to build a Silverblue installer image and install it
This is like the existing tests that build network install and
live images then install them, only for Silverblue. First we
build an ostree, using the standard configuration for the release
and subvariant but with the 'advisory' and 'workarounds' repos
included, so it will contain current stable packages plus the
packages from the update and any workarounds. Then we build an
ostree installer image with the ostree embedded, again including
advisory and workarounds repos in the installer build config so
packages from them will be included in the installer environment.
The image is uploaded, which completes the _ostree_build test.
Then an install_default_update_ostree test runs, which does a
standard install and boot from the installer image.
We do make a change that affects other tests, too. We now run
_advisory_post on live image install tests, as well as this new
ostree install image install test. It was skipped before because
of an exception that's really only needed for the netinst image
install test. In that test, packages from the update won't be
included in the installed system, so we can't run _advisory_post
on it. But for ostree and live image build/install tests, the
installed system *should* include packages from the update, so
we should check and make sure that it does.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-22 19:22:19 +00:00
|
|
|
# good to have the log around for checks
|
|
|
|
upload_logs "lorax.log", failok => 1;
|
|
|
|
assert_script_run "mv results/images/boot.iso ./${advortask}-${subv}-ostree-${arch}.iso";
|
|
|
|
upload_asset "./${advortask}-${subv}-ostree-${arch}.iso";
|
|
|
|
}
|
|
|
|
|
|
|
|
sub test_flags {
|
|
|
|
return {fatal => 1};
|
|
|
|
}
|
|
|
|
|
|
|
|
1;
|
|
|
|
|