os-autoinst-distri-rocky-mi.../tests/_advisory_post.pm

use base "installedtest";
use strict;
use testapi;
use utils;

sub run {
    my $self = shift;
    $self->root_console(tty => 3);
    # figure out which packages from the update actually got installed
    # (if any) as part of this test
    advisory_get_installed_packages;
    # figure out if we have a different version of any package from the
    # update installed
    advisory_check_nonmatching_packages;
}

sub test_flags {
    return {fatal => 1};
}

1;

# vim: set sw=4 et:
Update testing: log packages in update and installed packages Summary: This adds some logging related to the update testing workflow, so we have some idea what we actually tested. We log precisely which packages were actually downloaded from the update - this is important as updates can be edited and when examining results we'll want to know which packages actually got used. We also add a new module which runs at the end of postinstall and tries to figure out which packages from the update were installed in the course of the test. This still isn't a guarantee the test actually tested them in any way, but it at least means they got installed successfully and didn't interfere with the test. Test Plan: Run the update test workflow, check the logs get uploaded and seem accurate (sometimes some RPM garbage messages wind up in the package log, I'm not too worried about that at present). Run the compose test workflow and check it didn't break. Reviewers: jsedlak Reviewed By: jsedlak Subscribers: tflink Differential Revision: https://phab.qa.fedoraproject.org/D1149 2017-02-22 20:59:39 +00:00			`use base "installedtest";`
			`use strict;`
			`use testapi;`
			`use utils;`

			`sub run {`
			`my $self = shift;`
enforce standard coding on all Perl files 2023-02-12 22:59:37 +00:00			`$self->root_console(tty => 3);`
Update testing: log packages in update and installed packages Summary: This adds some logging related to the update testing workflow, so we have some idea what we actually tested. We log precisely which packages were actually downloaded from the update - this is important as updates can be edited and when examining results we'll want to know which packages actually got used. We also add a new module which runs at the end of postinstall and tries to figure out which packages from the update were installed in the course of the test. This still isn't a guarantee the test actually tested them in any way, but it at least means they got installed successfully and didn't interfere with the test. Test Plan: Run the update test workflow, check the logs get uploaded and seem accurate (sometimes some RPM garbage messages wind up in the package log, I'm not too worried about that at present). Run the compose test workflow and check it didn't break. Reviewers: jsedlak Reviewed By: jsedlak Subscribers: tflink Differential Revision: https://phab.qa.fedoraproject.org/D1149 2017-02-22 20:59:39 +00:00			`# figure out which packages from the update actually got installed`
			`# (if any) as part of this test`
Factor meat out of advisory_post and do it in postfail too If an update test fails before reaching advisory_post, we don't generate the 'what update packages were installed' and 'were any update packages not installed when they should have been' logs, but these may well be useful for diagnosing the failure - so let's also do the same stuff there. Only let's not do it all twice. Signed-off-by: Adam Williamson <awilliam@redhat.com> 2018-12-13 02:09:38 +00:00			`advisory_get_installed_packages;`
			`# figure out if we have a different version of any package from the`
			`# update installed`
			`advisory_check_nonmatching_packages;`
Update testing: log packages in update and installed packages Summary: This adds some logging related to the update testing workflow, so we have some idea what we actually tested. We log precisely which packages were actually downloaded from the update - this is important as updates can be edited and when examining results we'll want to know which packages actually got used. We also add a new module which runs at the end of postinstall and tries to figure out which packages from the update were installed in the course of the test. This still isn't a guarantee the test actually tested them in any way, but it at least means they got installed successfully and didn't interfere with the test. Test Plan: Run the update test workflow, check the logs get uploaded and seem accurate (sometimes some RPM garbage messages wind up in the package log, I'm not too worried about that at present). Run the compose test workflow and check it didn't break. Reviewers: jsedlak Reviewed By: jsedlak Subscribers: tflink Differential Revision: https://phab.qa.fedoraproject.org/D1149 2017-02-22 20:59:39 +00:00			`}`

			`sub test_flags {`
enforce standard coding on all Perl files 2023-02-12 22:59:37 +00:00			`return {fatal => 1};`
Update testing: log packages in update and installed packages Summary: This adds some logging related to the update testing workflow, so we have some idea what we actually tested. We log precisely which packages were actually downloaded from the update - this is important as updates can be edited and when examining results we'll want to know which packages actually got used. We also add a new module which runs at the end of postinstall and tries to figure out which packages from the update were installed in the course of the test. This still isn't a guarantee the test actually tested them in any way, but it at least means they got installed successfully and didn't interfere with the test. Test Plan: Run the update test workflow, check the logs get uploaded and seem accurate (sometimes some RPM garbage messages wind up in the package log, I'm not too worried about that at present). Run the compose test workflow and check it didn't break. Reviewers: jsedlak Reviewed By: jsedlak Subscribers: tflink Differential Revision: https://phab.qa.fedoraproject.org/D1149 2017-02-22 20:59:39 +00:00			`}`

			`1;`

			`# vim: set sw=4 et:`