New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify handling of potential not-implemented states of jobs #3877
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In production this will result in a 500 error page for the user and we'd still have to dig into the logs to find the exact error message. That's also not very nice. I'd rather put a warning somewhere on the web page if we consider this important enough or completely remove the code path. Or we'd simply add a category "other" where we would add the states/results to.
a880a33
to
5b3d1a3
Compare
Right, so if the die is handled that way by presenting 500 to the user then surely this PR in the current form is no improvement. I have a different preference though. An error in the logs is still better than in the webUI. The webUI is meant for users, the log for admins. That we don't look into logs (anymore) is our problem as admins. For that we also have https://github.com/os-autoinst/openqa-logwarn . But maybe an adjustment of your "other" proposal we can just count the unidentified as "unfinished" together. See my updated proposal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess counting these into unfinished makes sense. We handle already cancelled and done and it is unlikely that we introduce more "finished" states in the future.
Can you please add a description with e.g. a ticket or discription of what you're trying to achieve? |
Is the second line "Helps with statement coverage in tests as well :)" in the commit message enough? |
Not really. I'm still wondering what conversation or investigation this helps with "as well". |
Helps with statement coverage in tests as well :) Encountered while looking at code statement coverage reports on codecov, in particular https://codecov.io/gh/os-autoinst/openQA/src/master/lib/OpenQA/BuildResults.pm Related progress issue: https://progress.opensuse.org/issues/55364
5b3d1a3
to
fe29e53
Compare
@kalikiana updated the git commit message with more details and also a ticket reference and copied that into the PR description. |
created https://progress.opensuse.org/issues/92164 for the test failure which I consider unrelated. Will retrigger. |
I guess it's still failing because of poo#92164 although #3890 got merged - re-triggered again, let's see:
|
Codecov Report
@@ Coverage Diff @@
## master #3877 +/- ##
=======================================
Coverage 96.75% 96.76%
=======================================
Files 368 368
Lines 32798 32796 -2
=======================================
Hits 31735 31735
+ Misses 1063 1061 -2
Continue to review full report at Codecov.
|
Helps with statement coverage in tests as well :)
Encountered while looking at code statement coverage reports on codecov,
in particular
https://codecov.io/gh/os-autoinst/openQA/src/master/lib/OpenQA/BuildResults.pm
Related progress issue: https://progress.opensuse.org/issues/55364