Intermittent 0:31.62 testing/raptor/test/test_raptor.py::test_build_profile[RaptorAndroid-fennec] TEST-UNEXPECTED-FAIL: ADBError: [Errno 2] No such file or directory: adb is not executable.
Categories
(Testing :: Mozbase, defect, P5)
Tracking
(Not tracked)
People
(Reporter: intermittent-bug-filer, Unassigned)
References
Details
(Keywords: intermittent-failure, regression)
Filed by: hskupin [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=243558262&repo=try
Full log: https://queue.taskcluster.net/v1/task/c3LkIF_5SUmFG28zOTohRw/runs/0/artifacts/public/logs/live_backing.log
Maybe similar to bug 1454404, which I hit today by running Raptor Python tests on try.
|
||
Comment 1•5 years ago
|
||
[task 2019-04-30T08:51:15.262Z] 0:31.63 # catch early a missing or non executable adb command
[task 2019-04-30T08:51:15.262Z] 0:31.63 # and get the adb version while we are at it.
[task 2019-04-30T08:51:15.262Z] 0:31.63 try:
[task 2019-04-30T08:51:15.262Z] 0:31.63 output = subprocess.Popen([adb, 'version'],
[task 2019-04-30T08:51:15.263Z] 0:31.63 stdout=subprocess.PIPE,
[task 2019-04-30T08:51:15.263Z] 0:31.63 stderr=subprocess.PIPE).communicate()
[task 2019-04-30T08:51:15.263Z] 0:31.63 re_version = re.compile(r'Android Debug Bridge version (.*)')
[task 2019-04-30T08:51:15.263Z] 0:31.63 self._adb_version = re_version.match(output[0]).group(1)
[task 2019-04-30T08:51:15.263Z] 0:31.63
[task 2019-04-30T08:51:15.263Z] 0:31.63 except Exception as exc:
[task 2019-04-30T08:51:15.263Z] 0:31.63 > raise ADBError('%s: %s is not executable.' % (exc, adb))
[task 2019-04-30T08:51:15.264Z] 0:31.63 E ADBError: [Errno 2] No such file or directory: adb is not executable.
[task 2019-04-30T08:51:15.264Z] 0:31.63
[task 2019-04-30T08:51:15.264Z] 0:31.63 ../../../mozbase/mozdevice/mozdevice/adb.py:195: ADBError
Geoff, or Bob do you have an idea?
|
||
Comment 2•5 years ago
|
||
Perhaps the artifact build does not set the proper toolchains to install the android sdk? Try a non-artifact build and see how it does and if it passes, look into how the toolchains differ for the two types of build?
|
|
||
Comment 3•5 years ago
|
||
I pushed a new try build with --no-artifact. Lets see how this looks like:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=30cbd833a9a3cb0f962a9442d15086a058eb43d3
|
|
||
Comment 4•5 years ago
|
||
Looks like the same issue. Perhaps, gbrown will have a better idea.
|
||
Comment 5•5 years ago
|
||
When I look at this test on m-c, I see:
but in your try pushes I see that extended to Android:
https://hg.mozilla.org/try/rev/4cd143a915d1319612e2b5587dfd9e19f6e0dd52#l2.9
That's why the test is now trying to use adb. The problem is, adb is not normally installed on Linux/Windows hosts -- except for Android tasks.
|
|
||
Comment 6•5 years ago
|
||
No, those are two different tests. What you actually want is:
There hasn't been changed anything.
|
|
||
Comment 7•5 years ago
|
||
What I would do is a push to try but without your changes with a no-op change to raptor.py and/or test_raptor.py so it would invoke the source test. If that passes then there is something in your patch. If it doesn't pass, then we have another data point.
|
|
||
Comment 8•5 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #6)
No, those are two different tests. What you actually want is:
Agreed -- sorry!
I still think adb is not available in the automation test environment for python tests.
The existing fennec/geckoview tests in test_raptor.py seem quite minimal; I think they avoid any adb use. For instance,
Still, that test does create a RaptorAndroid instance, and with your changes, ADBDevice initialization now occurs in RaptorAndroid:
https://hg.mozilla.org/try/rev/cd34b9f579eed5f76035ea7e76bf5c2146abda9c#l1.106
so android test_build_profile now requires adb, which is not available; I think that is the issue.
|
|
||
Comment 9•5 years ago
|
||
Sorry, it's indeed caused by a change in my code which now creates an adbdevice by default for RaptorAndroid classes:
https://hg.mozilla.org/try/rev/cd34b9f579eed5f76035ea7e76bf5c2146abda9c#l1.106
But I still think this is the right way to do and that we have two options here:
- Figure out if we could have adb installed for python-test jobs
- If 1) is not possible that we have to mock adbdevice.
Andrew, what do you think of option 1)? Would that be possible or not?
This blocks landed my patch on bug 1528236.
|
||
Comment 10•5 years ago
|
||
Sure, should be possible using a fetch. I'd want the tests to be skipped locally if adb isn't detected though.
| Comment hidden (Intermittent Failures Robot) |
|
|
||
Comment 12•5 years ago
|
||
I decided to not take the current approach from bug 1528236, and reverted parts of the refactoring for now. It would still be possible to pick this work up again in the future.
Description
•