Closed
Bug 1492242
Opened 7 years ago
Closed 7 years ago
Use mozdevice for adb access in AndroidMixin
Categories
(Testing :: General, enhancement, P1)
Tracking
(firefox64 fixed)
RESOLVED
FIXED
mozilla64
| Tracking | Status | |
|---|---|---|
| firefox64 | --- | fixed |
People
(Reporter: gbrown, Assigned: gbrown)
Details
Attachments
(1 file, 2 obsolete files)
|
5.94 KB,
patch
|
bc
:
review+
|
Details | Diff | Splinter Review |
AndroidMixin uses subprocess to invoke adb directly for some functions. It might be advantageous to use mozdevice instead.
| Assignee | ||
Updated•7 years ago
|
Assignee: nobody → gbrown
| Assignee | ||
Comment 1•7 years ago
|
||
But mozdevice is not part of the mozharness package, so mozharness scripts do not have access to it. mozharness uses some other mozbase projects, like mozprocess, but this has been made possible by copying code from mozbase into mozharness -- ugly, inconvenient, and error prone (copies of mozbase projects always seem to become out-of-sync with the original).
| Assignee | ||
Comment 2•7 years ago
|
||
:bc - I believe you want to use mozdevice for adb access everywhere, including mozharness, and I think that's a good goal. For mozharness, there is the complication that mozdevice is not easily available to mozharness. We have made other mozbase projects available to mozharness by copying the mozbase project under mozharness (like https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/mozprocess) but I don't like the code duplication or mozharness code bloat caused by that approach.
Here's an alternative: Call adb from a separate process via this adb_cmd.py wrapper -- it will pick up the mozdevice that is pip installed by the mozharness script. Pretty simple so far, but if we go this way, adb_cmd.py would be extended over time to handle pass-through of more and more mozdevice capabilities. What do you think of the approach?
Attachment #9010407 -
Flags: review?(bob)
Comment 3•7 years ago
|
||
President Not Sure says: "Let me think about that for a bit."
| Assignee | ||
Comment 4•7 years ago
|
||
| Assignee | ||
Comment 5•7 years ago
|
||
Comment on attachment 9010407 [details] [diff] [review]
wrap mozdevice with adb_cmd.py
There is a better way...
Attachment #9010407 -
Flags: review?(bob)
| Assignee | ||
Comment 6•7 years ago
|
||
Still runs fine locally (emulator/ubuntu host) and on try:
https://treeherder.mozilla.org/#/jobs?repo=try&tier=1%2C2%2C3&revision=394ac696cc083527e509d7d3af3395987a3d62a6
logcat remains a special snowflake for now, and I expect AndroidMixin to grow with bug 1492239 and bug 1492240, but I think this is a good start.
Attachment #9010407 -
Attachment is obsolete: true
Attachment #9010457 -
Flags: review?(bob)
Comment 7•7 years ago
|
||
Comment on attachment 9010457 [details] [diff] [review]
use mozdevice in AndroidMixin
Review of attachment 9010457 [details] [diff] [review]:
-----------------------------------------------------------------
Overall this is absolutely great! Some minor tweaks on the handling of failure to install.
::: testing/mozharness/mozharness/mozilla/testing/android.py
@@ +127,3 @@
> self.fatal('INFRA-ERROR: Failed to install %s on %s' %
> (self.installer_path, self.device_name),
> EXIT_STATUS_DICT[TBPL_RETRY])
Should return False here.
@@ +127,4 @@
> self.fatal('INFRA-ERROR: Failed to install %s on %s' %
> (self.installer_path, self.device_name),
> EXIT_STATUS_DICT[TBPL_RETRY])
> + return True
We don't actually use the return value...
::: testing/mozharness/mozharness/mozilla/testing/raptor.py
@@ +366,4 @@
>
> def install(self):
> if self.app == "geckoview":
> + self.install_apk(self.installer_path)
We should either check the return value here and then terminate gracefully if it fails or remove the return value from the install_apk and just let the exception kill us.
Attachment #9010457 -
Flags: review?(bob)
| Assignee | ||
Updated•7 years ago
|
Priority: -- → P1
| Assignee | ||
Comment 8•7 years ago
|
||
I removed the return from install_apk(). On failure, self.fatal() should bring execution to a halt and also trigger a task retry (where supported). I also considered removing the catch/fatal and relying on the ADBError; I prefer the fatal() for its specific error message and continuity with existing error handling.
Attachment #9010457 -
Attachment is obsolete: true
Attachment #9010735 -
Flags: review?(bob)
Comment 9•7 years ago
|
||
Comment on attachment 9010735 [details] [diff] [review]
use mozdevice in AndroidMixin
Review of attachment 9010735 [details] [diff] [review]:
-----------------------------------------------------------------
lgtm. thanks!
Attachment #9010735 -
Flags: review?(bob) → review+
Comment 10•7 years ago
|
||
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1fbe78137004
Use mozdevice to access adb in mozharness AndroidMixin; r=bc
Comment 11•7 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox64:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in
before you can comment on or make changes to this bug.
Description
•