action #115319
Updated by JERiveraMoya over 1 year ago
#### Motivation ####
In general the flow of the screen is predictable and we can fix expectation, but there are some corner cases where this is not true.
Example of this are for example these two:
Product selection is something that normally happens during installation, but if there is only one product to select, for example in s390x when no SUMA available for a while during product development, this screen doesn't appear.
https://openqa.suse.de/tests/9313573#step/accept_license/1
https://openqa.suse.de/tests/8751121#step/accept_license/1
Beta acceptance is also something that happen until certain point during product development
https://openqa.suse.de/tests/9313573#step/access_beta_distribution/1
https://openqa.suse.de/tests/8751121#step/accept_license/1
We have available mechanism with default+flow to achieve that.
#### Acceptance criteria ####
**AC1**: The problem with no product selection is solved using yaml feature default+flows.
**AC2**: Solution is applied to select_modules_and_patterns+registration@s390x-kvm-sle12
#### Suggestions ####
As we are actually testing the final product, we can say that the default should be how it will look in GM. Then on top of that we can add our flows to modify that behavior.
We could create a flow `no_product_selection.yaml` which will clean up the key `product_selection` in default.yaml making it an empty hook and add this flow to all test suite in s390x. The problem is that we need to add that flow to all the test suite in one architecture. In this case I think **it would make more sense** to create default_s390x.yaml. You can reuse default.yaml and use merge keys mechanism to update **in one place** this behavior.
With this change we should fix the following two test cases besides solving the beta issues after publicbeta:
https://openqa.suse.de/tests/9313573#step/accept_license/1
https://openqa.suse.de/tests/9313575#step/accept_license/1
The beta problem is for all the architectures, so we can rely on default.yaml and update it in single place when corresponding. Nothing to do then, only to migrate test suite to this new mechanism in follow-up tickets.