1
0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-04 23:24:21 +00:00
Commit Graph

10 Commits

Author SHA1 Message Date
Adam Williamson
282ecb6c32 Revert "zezere: tweak for web UI change"
This reverts commit 2fecb70468.
Sadly, clicking on the right menu entry...doesn't work. Let's
try going back to the old way, but add an 'enter' press once
the entry we want is selected.
2023-03-02 15:02:14 -08:00
Adam Williamson
2fecb70468 zezere: tweak for web UI change
The runrequest list is just a normal dropdown menu now, so we
can just click the thing we want.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-03-02 14:39:00 -08:00
Adam Williamson
1a65993d36 Add a perltidy check and apply it to the entire codebase
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-07-28 14:38:38 -07:00
Adam Williamson
4971de39e9 Tweak quit_firefox to handle hang on exit on ppc64le (#2094137)
It seems when we quit Firefox back to a VT on ppc64le, the system
hangs. Not sure why, but we can deal with it by rebooting the
system and logging back in as root if it happens. Also take the
opportunity to clean up the flow of quit_firefox so we always
check that we get back to a console then wait 5 seconds for the
console to settle, so all the tests that call it can stop doing
that.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-06-06 18:35:52 -07:00
Adam Williamson
108fb457c6 Try to stabilize Zezere remote test with a wait_still_screen
Saw a failure where Firefox UI had not fully loaded yet so the
click area changed.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-04-08 12:28:17 -07:00
Adam Williamson
b57b306d4b _iot_zezere_remote: be careful when quitting firefox
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 13:52:07 -07:00
Adam Williamson
387b09a53a Fix previous zezere change (use single quotes)
Stupid @.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-21 16:03:14 -07:00
Adam Williamson
30ab26fbe6 Tweak _iot_zezere_remote to keep retrying ssh for up to 10 mins
The time before the ssh key provision request goes through turns
out to be kinda unpredictable, so instead of just a hardcoded
wait then assuming it should succeed, let's do a loop-y retry
thing instead.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-21 15:02:01 -07:00
Adam Williamson
755ac778cc Wait longer for Zezere provision request to go through
30 seconds doesn't seem to be reliable enough. Let's try 60, if
that's not enough I'll try and think of something smarter.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-07 16:25:07 -07:00
Adam Williamson
aa41fe4e4e Automate QA:Testcase_Zezere_Ignition
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.

So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.

Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-23 18:01:06 -07:00