upload Anaconda ABRT directory
ClosedPublic

Authored by garretraziel on Mar 18 2015, 2:17 PM.

Details

Summary

I have discussed it with Anaconda guys and found out that
clicking on "Report" button when Anaconda's error dialog is displayed
creates ABRT report directory (that you can then download and report
from your computer).

Test Plan

Since Beta TC2 is currently broken, just run any test
and observe that var_tmp.tar.gz file appears in uploaded logs.

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.
garretraziel retitled this revision from to upload Anaconda ABRT directory.Mar 18 2015, 2:17 PM
garretraziel updated this object.
garretraziel edited the test plan for this revision. (Show Details)
garretraziel added reviewers: adamwill, jskladan.

I'm working on having openQA actually file a bug, when it crashes (this also will be a test of report submission). The biggest problem so far is capturing the ID of the bug it reports; this doesn't seem to be logged anywhere and I'm not super-sure about openQA's ocr stuff, upstream doesn't seem to use it a lot. But I'm working on it.

I suppose another way to go about it would be to have the worker upload the report (as this patch achieves), and have the dispatcher handle reporting bugs; as it's running out in Python-land we probably have more flexibility there.

This patch mostly looks fine to me, I worry slightly about the use of assert_and_click because if the dialog changes a bit in the wrong way, so the ID needle still matches but the report button needle doesn't, I think we'll then die there and uploading of other logs won't happen. Unfortunately there doesn't seem to be a test_and_click or anything, we'd have to handle the error from assert_and_click if we want to continue even if it fails, I think.

I'd recommend combining anaconda_error and anaconda_report_btn into one needle with a match on the 'An unknown error has occurred' text and a smaller match on the 'Report Bug' button. Then you can just check_screen and then assert_and_click the same needle; it saves one needle and is more robust against the problem I pointed out above.

I think that uploading logs and reporting from dispatcher is better solution than reporting directly from OpenQA - because you can still download var_tmp.tar.gz and report it from your computer when reporting on VM fails.

About combining two needles into one - I am not fond of this OpenQA behaviour (that it clicks on smallest match) and I am currently planning to either open feature request or make pull request about it. I think that better solution is how it was done in infinity - let user define where to click independently of where to match.

... I am not fond of this OpenQA behaviour (that it clicks on smallest match) and I am currently planning to either open feature request or make pull request about it...

+1, this is as arbitrary as it gets. It might seem like "wasting" (having a separate needle just for assert_and_click), but the maintainability hugely overpowers it. Once the "clickable" area is configurable, I'm all for making it into one needle, but before it happens, I'm strongly supporting the "separate-needle-for-clicking" approach.

Again about bugreporting - I have talked with jfilak who is from libreport/ABRT team and he said that he is able to make libreport run on OpenSUSE and add plugin to libreport so that it would upload all necessary files to OpenQA by itself - that would make this differential request unnecessary.

What's better, he also said that he is willing to add "Report to Bugzilla" button to OpenQA and I think that this is absolutely the best approach - user would be able to review testrun and if he decides that it should be reported to bugzilla, he can do it with single click. And if we want to be able to report things automatically, having this functionality would simplify it for us. I have made feature request for it on libreport's github https://github.com/abrt/libreport/issues/340

That sounds nice, though I'd like it to be usable from the API: a button in the web UI sounds nice and 'easy' when we have ten tests for each compose and we run the tests like once a day, but what about when we have 200 tests and we run six times a day? That gets to be a lot of 'trawl through the failures and click on the report crash button' work :)

so, I'd like the openQA implementation to come with an API request interface. I'd also be worried about forking openQA; have we talked to openQA upstream about this and verified whether they'll accept a patch for this libreport feature, or at least if we can do it as a plugin (openQA seems to have plugins...and that's just about all I know) if they won't take the patch?

In D310#5621, @jskladan wrote:

... I am not fond of this OpenQA behaviour (that it clicks on smallest match) and I am currently planning to either open feature request or make pull request about it...

+1, this is as arbitrary as it gets. It might seem like "wasting" (having a separate needle just for assert_and_click), but the maintainability hugely overpowers it. Once the "clickable" area is configurable, I'm all for making it into one needle, but before it happens, I'm strongly supporting the "separate-needle-for-clicking" approach.

Eh, I'm still not sure I agree. Sure it's 'arbitrary', but it's clearly defined and reliable. Being able to choose the clickable area would be better, sure, but it's perfectly easy to work with the current behaviour.

Still, if that's the way you want to go, fine, but can we at least have the 'identification' needle also match on the report button, so we know it will be there for the 'click' needle to click?

In D310#5673, @adamwill wrote:

Eh, I'm still not sure I agree. Sure it's 'arbitrary', but it's clearly defined and reliable. Being able to choose the clickable area would be better, sure, but it's perfectly easy to work with the current behaviour.

That is true, of course, but I don't want to count the space of all the areas in a needle to be sure that the one I want to click-at is the smallest one and, at the same time reliable enough to identify just the area to click on.

Still, if that's the way you want to go, fine, but can we at least have the 'identification' needle also match on the report button, so we know it will be there for the 'click' needle to click?

Absolutely, this is how I'd like it to be set up - match the screen with all the pieces required, and then just have a special one-area-needle to decide on the clickable area.

In D310#5672, @adamwill wrote:

That sounds nice, though I'd like it to be usable from the API

Me too and I think that having this functionality in OpenQA is a good start.

I'd also be worried about forking openQA

+1, forking openQA is not intended - jfilak said that this could be functionality upstream would be interested in too.

have we talked to openQA upstream about this and verified whether they'll accept a patch for this libreport feature, or at least if we can do it as a plugin (openQA seems to have plugins...and that's just about all I know) if they won't take the patch?

Not yet, I'm waiting on jfilak's response.

Still, if that's the way you want to go, fine, but can we at least have the 'identification' needle also match on the report button, so we know it will be there for the 'click' needle to click?

That's true. I will go through needles and correct it.

jskladan accepted this revision.Apr 3 2015, 8:21 AM

Please merge. Or abandon, if the functionality is provided in an other, equivalent way.

This revision is now accepted and ready to land.Apr 3 2015, 8:21 AM
Closed by commit rOPENQATESTS469d8d2e925a: upload Anaconda ABRT directory (authored by Garret Raziel <boloomka@gmail.com>). · Explain WhyApr 3 2015, 11:44 AM
This revision was automatically updated to reflect the committed changes.