-
Notifications
You must be signed in to change notification settings - Fork 49
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
Monitor Launchpad binary builds (Infra) #880
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.
lp_build_monitor_recipe.py
is missing the +x
execute bit.
028b960
to
2b2f769
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #880 +/- ##
==========================================
+ Coverage 36.06% 36.11% +0.05%
==========================================
Files 310 310
Lines 34603 34631 +28
Branches 5965 5968 +3
==========================================
+ Hits 12478 12506 +28
+ Misses 21562 21561 -1
- Partials 563 564 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I'm marking this as draft as the current implementation doesn't retry for builds fast enough. I have an idea on how to make it better but it needs more testing |
8fe2649
to
3f5eb7f
Compare
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.
Some comments inline, more incoming in ~2h
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.
The one thing I need more clarity is the typing story...
So previously there was an unknown type of "LPBuild". In the latest change you introduce that type and make it an alias of the LP's Entry. So there wasn't an original LPBuild defined anywhere in the lplib? (even the proxy)
If those functions always returned "Entry" I'd be happy with specifying this type. If you want to do a stricter typing, I guess you'd have to create a proper hierarchy. The classes that are here now are just all different names for the Entry
class.
What do you think? Do you see value in having those aliases for Entry right now? (I'm not saying there is none :) )
There is no type beside Entry, that is sadly how the launchpadlib api works. I want to have a type reference there because it is very hard to keep track of which web api each "entry" actually refers to. Each of those entries have some valid attribute and function calls to them, the only way to know which is to know which web api they are calling or, at runtime, inspecting the |
Perfect justification, thank you! |
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.
Perfection, +1
* Renamed get_build_recipe to get_source_build_recipe * Actually monitor bin builds * Removed debug code * Fixed and updated all tests * Roll back debug LP_POLLING_DELAY * Fast retry while any build is ongoing * Better type hints * Docstrings for all functions in the module * cycle -> iteration * Removed pass and fixed typo * Documented Launchpadlib objects in a class docstring * Minor: removed s and replace forgotten entry
* Renamed get_build_recipe to get_source_build_recipe * Actually monitor bin builds * Removed debug code * Fixed and updated all tests * Roll back debug LP_POLLING_DELAY * Fast retry while any build is ongoing * Better type hints * Docstrings for all functions in the module * cycle -> iteration * Removed pass and fixed typo * Documented Launchpadlib objects in a class docstring * Minor: removed s and replace forgotten entry
* Renamed get_build_recipe to get_source_build_recipe * Actually monitor bin builds * Removed debug code * Fixed and updated all tests * Roll back debug LP_POLLING_DELAY * Fast retry while any build is ongoing * Better type hints * Docstrings for all functions in the module * cycle -> iteration * Removed pass and fixed typo * Documented Launchpadlib objects in a class docstring * Minor: removed s and replace forgotten entry
Description
The new script only monitors source builds but binary builds do (and infact are more likely) to fail as well. This introduces a new waiting mechanism for binary builds and monitors/retries them the same way source builds are.
Resolved issues
The current script fails to monitor binary builds.
Documentation
This changes all names where necessary and documents the workarounds that were needed (namely, there does not seem to exist an api that lists (actually)pending binary builds on a launchpad ppa)
Tests
This comes with some new tests and updates those that were there before