Limit to Env Checkbox for Entities and View for #7333

[latran]

This is new implementation to give users more control of the checkboxes under Content Host Repository Sets.

[mirekdlugosz]

Lai,

After some experimentation, I arrived to two possible solutions. As far as I can tell, both give the same results.

Solution 1:
Use test_positive_sample from https://github.com/mirzal/robottelo/blob/ltran-chost-lce/tests/foreman/ui/test_contentview.py#L120 and new contenthost.read() from https://github.com/mirzal/airgun/blob/f8b9abba74cf4c2cf6eca488ef4f814f31b6725c/airgun/entities/contenthost.py#L36 .
The idea here is that read() method gets new argument. If this argument is passed in, instead of reading all the widgets, we read all the widgets except repository_sets. Then we check the checkbox, read repository_sets and merge all the results before returning them.
From caller perspective, there is just one new argument in function signature. However, this approach will be very hard to scale once you want to do changes to view before reading multiple widgets. Overall, it works, but you can feel that framework is working against you here and this is not exactly the thing you should do.

Solution 2:
Use test_positive_sample2 from https://github.com/mirzal/robottelo/blob/ltran-chost-lce/tests/foreman/ui/test_contentview.py#L130 . No changes to Airgun required.
Here, we split contenthost.read() to multiple calls on test side. First, we read all widgets expect repository_sets. Then, we select specific checkbox on this tab using contenthost.update(). Finally, we read only this specific tab. If it is required, results dictionaries can be merged, but you can simply run assertions on two dictionaries.

Solution number 2 is not something we often do in Robottelo, but requires so much less changes than solution 1. Overall, I feel it's much more aligned with spirit of frameworks that we use.

I also asked widgetastic developers for their opinion on how problems like that should be approached: RedHatQE/widgetastic.core#158

[latran]

@Mirzal I have this bit of code working when running it locally alongside SatelliteQE/robottelo#7334. But when I try to run it in the terminal, it just hangs. Any idea on what's going on? I've try both old and new implementation and it's just handing in the errata installation task details page. Am I using the wrong calling method to make sure that it's installing correctly and finishes?
@swadeley Have a look as well and try to run it via terminal and see what result you get.

[mirekdlugosz]

@latran calls look OK to me. They are used elsewhere, too.

contenthost.install_errata calls views/job_invocation.py::JobInvocationStatusView.wait_for_result, which can wait up to 20 minutes before eventually failing (two wait-for calls, each with 10 minutes timeout). How long did you wait? Is it possible that it still worked, just was extremely slow, so you mistakenly took it as hanged?

Have you seen browser window when it hanged? If I understand correctly, install_errata will navigate to job summary view, where progress bar should be displayed. Did it fill to 100%? if you still have access to that environment, or can re-create it easily, can you verify if elements we check still exist on web page? Maybe we wait until element is displayed, but that element was removed and we will never find it...

Probably not, as you mentioned it is working when running locally, but hanging when running in terminal. I don't understad that part. Could you explain?

[latran]

@mirekdlugosz What I mean is that when I go to the command line and run this: "pytest tests/foreman/ui/test_contenthost.py::test_positive_end_to_end" the operation hangs once installing errata reached a successful state and the progressbar reached 100%. It's as if views/job_invocation.py::JobInvocationStatusView.wait_for_result and views/errata.py::ErrataTaskDetailsView method calls are not working properly or needs some fine tuning.

The approximately wait time was around 5 minutes before the call ends. Here's a pastebin of my result: http://pastebin.test.redhat.com/801669

[mirekdlugosz]

@latran I'm so sorry, but your situation is not entirely clear to me.

This test fails, right?
It fails every time you try, correct? I understood that depending on how you start it, it may pass or fail. That was misunderstanding and your results are stable, correct?
It goes up to the point of installing errata. At this point, page looks like everything is alright, but test sits here for some 5 minutes. After that time, it fails. Correct?

Unfortunately, this log contains only warnings, which are not useful at all. Do you have stacktrace available? You can even post everything from invocation up to next command line prompt. Better to post too much details than not enough.

[latran]

This is not needed anymore. This PR can be deleted

[latran]

not needed anymore