tweak two disk matching to be more robust
ClosedPublic

Authored by adamwill on Jul 22 2015, 2:29 AM.

Details

Summary

Depending on the disks attached to the system and some other
idiosyncracries (like what the disk 'description' currently
happens to be), the distance between the two disk icons can
vary, so a needle that matches on the two disk icons is fragile
(whenever the distance differs, the match fails). So instead of
that, let's have a needle that matches on a single icon with
a lot of grey space to its left, plus the two little matches
we later use in the select_disk(1/2) needles. This should be
robust enough and doesn't need us to keep duplicating it when
the distance between the icons changes. With this tweak, the
'2' variant is no longer needed.

Test Plan

Run the various tests that use two disks and check this
needle always matches. You'll also want to have D456 applied.

Diff Detail

Repository
rOPENQATESTS os-autoinst-distri-fedora
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
adamwill retitled this revision from to tweak two disk matching to be more robust.Jul 22 2015, 2:29 AM
adamwill updated this object.
adamwill edited the test plan for this revision. (Show Details)
adamwill added reviewers: jskladan, garretraziel.
garretraziel accepted this revision.Jul 22 2015, 7:30 AM

Note that this wouldn't work if the disks were too close to each other. Another solution would be to click on one of the disks and then check that both needles - selected and unselected disk - are present.

But I would merge this and deal with problems when (if) they appear.

This revision is now accepted and ready to land.Jul 22 2015, 7:30 AM
adamwill added a comment.EditedJul 22 2015, 7:45 AM

I based the gap in this commit on F23 with two virtio disks, which is the smallest gap so far (between F22 and F23 something changed in kernel/udev so they're given those weird hex-y identifiers, which is why this started breaking in the first place). I guess if they were single digits in size the gap would be a bit smaller, but I left a bit of a cushion, so I think it'd still be OK. At this point it's the 'vdX / XX GiB free' line determining the width of the elements, so the gap can only get narrower if that line gets shorter.

jskladan accepted this revision.Jul 22 2015, 12:22 PM

I think this is as good solution as it gets now. Let's do this, and fix errors, if there are any in the future (yay for making this the future-me problem!)

This revision was automatically updated to reflect the committed changes.