Replace blivet tests with custom GUI tests #51
No reviewers
Labels
No Label
priority: critical
priority: high
priority: low
priority: medium
status: abandoned
status: duplicate
status: invalid
status: peer review needed
status: wontfix
tag: content
tag: good first issue
tag: help wanted
test suite
type: bug
type: documentation
type: enhancement
type: maintenance
type: question
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: testing/os-autoinst-distri-rocky-migrated#51
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "issue_9"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
This pull request includes all resources needed to replace the blivet partitioning GUI tests with tests written specifically for the Rocky-included "custom" partitioning GUI. Fixes #9.
How has this been tested?
I reloaded the FIF templates and executed the tests as follows:
With this PR, the suites
install_custom_gui_lvm_ext4@uefi
andinstall_custom_gui_lvm_ext4@64bit
softfail with some AVCs, but otherwise pass.Checklist
As we talked already in MM/IRC, beside a few needles which could have a better detection box, everything looks really good up to now!
install_custom_gui_lvm_ext4@64bit
was a soft fail (only) for theavc: denied { getattr } for pid=### comm="login"
we are often seeing otherwisedisk_custom_lvm_ext4_postinstall
passed.Ran another round, also after the rebase everything looks good!
This is probably a Perl question, but I wanted to call out this behavior and get some team insight. Currently the
raidl
arg is specified as an int; I suspect specifying it as a string would make this problem go away, but that feels lazy. What is the correct way to handle this behavior in this case?My guess without digging further is that this is intended as a boolean value (Perl doesn't have a true Boolean type) where
(int)0
=FALSE
and all other values areTRUE
in theif()
statement. Looking through other test files (like the postinstall check) it seems only RAID1 is currently supported although this isn't clearly documented.Okay I can confirm now, all test suites behave normal!
The new tests and needles work as they should 👌🏻
I looked a bit further through the code and I have to say... I found a mismatch 🤔
The only place such similar parameter is used is in
disk_custom_gui_software_raid.pm:23
which uses the parameterraidl
(most likely for raidlevel) with the integer 1 for I suppose raid level 1This means we should either rewrite the one usage in line
disk_custom_gui_software_raid.pm:23
or might be better, for future awareness, changeraid1
in the lines of anaconda.pm 185, 191 and 233 toraidl
,uncomment lines 238 and 239 and comment or remove 240.
Just have noticed that the whole section is new, as well as the whole disk_custom_guid_software_raid.pm ... so yeah if I reread what I have written, I'm still on the point that it should be called
raidl
orraidlevel
, as I think this should not be limited to raid 1Off course this will make more work to make sure you have enough disks for the different raidlevels but I just wouldn't make it limited to raid1 🤔
Looked through everything again, and also checked the raid install in detail, looks good ✔
@ -0,0 +12,4 @@
"tags": [
"ENV-DISTRI-rocky",
"LANGUAGE-english",
"anaconda_custom_part_add"
Not critical but you didn't specify
LANGUAGE-english
in this needle.It's unclear to me why there are three needles matching for
anaconda_custom_size
. They have slightly different locations and the two have a click but one does not. In mydisk_custom_gui_standard_partition_ext4@x86_64
test the needle matched here isrocky-anaconda_custom_size-20211010
. Arerocky-anaconda_custom_size-20211005
androcky-anaconda_custom_size-20211007
needed at all?After some backflips in my test machine (all my own issues) all non-UEFI passed in the partitioning steps for
@x86_64
(I cannot test UEFI or aarch64). Tests had soft fails for AVC in_consolve_avc_crash
only.See comments about possibly unneeded needles. It might be good now to see if / where these are actually matching (if they are) as it seems unnecessary to have three different needles for the same match (unless it is).
An explanation of that and plan to address (if needed) is all that should be necessary to get full approval and merge.
I don't think those needles are needed at all. I have removed them in my most recent commit and am rerunning all the tests to make sure nothing broke.