-
Notifications
You must be signed in to change notification settings - Fork 604
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
tests: translated log-analyzer script from bash to python #15180
tests: translated log-analyzer script from bash to python #15180
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #15180 +/- ##
==========================================
+ Coverage 78.06% 78.17% +0.11%
==========================================
Files 1183 1192 +9
Lines 158250 159589 +1339
==========================================
+ Hits 123541 124763 +1222
- Misses 27029 27099 +70
- Partials 7680 7727 +47
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Fri Mar 21 11:07:03 UTC 2025 Spread tests skipped |
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.
Has this already landed in snapd-testing-tools?
5d736e9
to
7e92fa6
Compare
Thanks for pointing that out. I opened a PR there canonical/snapd-testing-tools#57 |
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.
Thank you for tackling this problem. This much welcome improvement.
I left a few quick comments but I'd really like to see type annotations and type-clean mypy --strict
pass. Those little utilities tend to break from time to time and when one tries to reverse engineer what's going on it's often that the types fall apart in some edge cases - exactly what mypy can automatically help figure out.
I'm super happy to see unit tests, this is exactly what we should have always done.
I left some more comments on argument parsing details. I think you can really refactor that part and get very clean code with great user experience (--help
and the like).
One word of caution, I'm not sure exactly if we are bound by python version requirements to run this (do we ever run this with ancient python?) I'd be really good to clearly document that in the log analyzer itself, as a longer code comment.
4d6738e
to
807af21
Compare
Signed-off-by: Zygmunt Krynicki <[email protected]>
This has remaining, unfixed type bug that needs to be discussed. Signed-off-by: Zygmunt Krynicki <[email protected]>
from typing import Callable, TypedDict | ||
|
||
|
||
class SpreadLog(TypedDict): |
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 had a longer look on this and I think the fundamental problem is that the fields are all optional depending on the type. We really have an union of several types. This has become more evident as I started to look at tests.
@maykathm I've pushed a change that tries to illustrate the remaining type problem (and indeed a realization that the underlying data format is just weakly specified):
Have a look at the patches I've pushed to this branch please. |
def _get_detail_lines( | ||
spread_logs: list[SpreadLog], log_condition_func: Callable[[SpreadLog], bool] | ||
) -> list[str]: | ||
result = [log["detail"]["lines"] for log in spread_logs if log_condition_func(log)] |
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.
Do all the log "types" have a detail that has lines?
type: Literal["result"] | ||
result_type: str | ||
level: str | ||
stage: str |
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'd love to have a literal/enum that lists all known stages.
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 believe the stage is read directly from the spread log so it is just the stages in spread: prepare, restore, execute
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.
Thanks, I'll do a follow-up that tries to make this more explicit.
add_arguments(reexecute) | ||
list_all.add_argument( | ||
"exec_params", | ||
help="This is the parameter used to run spread (something like this BACKEND:SYSTEM:SUITE)", |
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.
Nitpick, this is copy-pasted from and shares a sibling above. We should clarify that the list is comma-separated or use nargs='+'
if this does not break external format constraints.
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.
LGTM! Thank you!
I'd like to do a follow-up that moves some of the python types module as we will have more and more scripts that kind of do the same thing and I'd like to implement it fewer rather than more times.
Thanks for this improvement. Also I think we need to clean the backends/systems we have in out spread.yaml because spread in order to list the jobs that match with the filter, calculates all the combinations and then apply the filter to all the jobs. |
Please, remember that we need to apply all the changes to snapd-testing-tools first, and then import on this branch those changes. |
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.
thanks
I blocked this pr until the change is imported from snapd-testing-tools |
… quoted run tests
This replaces the log-analyzer script from bash to python. The bash script, because of many calls to
spread -list
when getting the list of tasks to reexecute, could require upwards of 20 minutes to execute. The new Python script will callspread -list
exactly once. This additionally adds some python unit tests to ensure the script's correctness.