As of today's FESCo meeting (logs pending), the anaconda webUI change is approved for F42. That means we need to substantially expand the scope of testing on it to be as close as possible to the testing done on gtkui, since it'll be present in a release-blocking path. Right now we just run one very simple install test, essentially a smoke test. We need to cover all the partitioning stuff that webUI is capable of, and anything else the UI exposes. This will be a substantial chunk of work.
@jkonecny fyi
@kkoukiou is the best contact for you if you need anything
So I did some very preliminary poking about at this today. Tentative conclusion: I think we can just kinda use the existing partition test loading logic in main.pm, which is pretty simple:
## Disk partitioning. # If PARTITIONING is set, we pick the storage test # to run based on the value (usually we run the test with the name # that matches the value, except for a couple of commented cases). my $storage = ''; my $partitioning = get_var('PARTITIONING'); # if PARTITIONING is unset, or one of [...], use disk_guided_empty, # which is the simplest / 'default' case. if (!$partitioning || $partitioning ~~ ['guided_empty', 'guided_free_space']) { $storage = "tests/disk_guided_empty.pm"; } else { $storage = "tests/disk_" . $partitioning . ".pm"; } autotest::loadtest $storage; if (get_var("ENCRYPT_PASSWORD")) { autotest::loadtest "tests/disk_guided_encrypted.pm"; }
So we can have tests named disk_webui_btrfs_preserve_home with PARTITIONING set to webui_btrfs_preserve_home, disk_webui_delete_partial with PARTITIONING set to webui_delete_partial and so on. I think that should mostly work fine.
disk_webui_btrfs_preserve_home
PARTITIONING
webui_btrfs_preserve_home
disk_webui_delete_partial
webui_delete_partial
These are the possible flows through current webUI partitioning:
So looking at existing tests...um...
So...that looks kinda manageable, on the whole. And it shouldn't be too hard for us to split up the work as it doesn't need much co-ordination. We do probably want a library with functions for doing stuff in the "custom" workflow, though, like we do for gtkui custom and blivet. We can add those to anaconda.pm or have a new one.
@lruzicka wdyt?
I started working on this today on the webui-custom branch, but ran into a couple of anaconda bugs that are sort of throwing a spanner in the works: https://bugzilla.redhat.com/show_bug.cgi?id=2336488 and https://bugzilla.redhat.com/show_bug.cgi?id=2336489 . I don't really want to put a bunch of logic in the tests to work around those, hopefully we can get quick fixes instead. @kkoukiou heads up
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/pull-request/353 adds an initial webui custom install test (xfs).
Yeah, thank you for the exhaustive exploration of the topic. I did not go through all of the tests per se, just through the provided list of yours, I have a couple of remarks so far:
install_btrfs
Use entire disk
Reinstall Fedora
Log in to comment on this ticket.