coordination #93668: [epic] Redesign Installation test modules
Leave only one getter for GuidedSetupController in Distribution::Opensuse::Tumbleweed
Currently, two getters for GuidedSetupController are specified in Distribution::Opensuse::Tumbleweed:
get_guided_partitioner. We should refactor this to have only one getter. That will make our structure consistent and allow to use DistributionProvider to control which GuidedSetupController to use for the certain version of product.
- Leave only one getter for GuidedSetupController in Distribution::Opensuse::Tumbleweed (The one which is pointing to
- Make sure that there are no failures in test runs (e.g. in YaST job Group, openSUSE Tumbleweed, Leap 15, Maintenance tests (https://openqa.suse.de/group_overview/321));
- Implement methods in
Installation::Partitioner::LibstorageNG::v4_3::GuidedSetupControllerthat will be required to pass
encrypt_lvm_reuse_existingand others, that still use old Installation::Partitioner::LibstorageNG::GuidedSetupController
- Consider migrating one at a time from one controller to the other and ask for review for after each case. Ticket might need to be split.
- The other option is to do a pure refactor and move all the methods without further modifications.
#6 Updated by oorlov about 2 months ago
This PR includes refactoring of the pages, controllers and test modules for Guided Setup.
Schedules changed only for cryptlvm and crypt_no_lvm scenarios to reduce scope for review and eliminate potential mistakes. Other schedules will be covered in further PRs.
- Status changed from In Progress to Resolved
PR for guided_setup and encrypt_lvm_ignore_existing: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/13646
PR for lvm and lvm_no_separate_home: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/13512
The initial task is not reached: the getter for GuidedSetupController on 15-SP2 is kept, but for SP3, SP4 we refactored the guided setup test modules to make them more transparent and atomic. As Sp2 still use needles approach and LibyuiClient cannot be applied there, we'll keep the existing getter for now. In case it will be required in future, we'll rewrite it in the follow-up tickets.