Closed Bug 810096 Opened 12 years ago Closed 12 years ago

Clean up internal variables in mozdevice

Categories

(Testing :: Mozbase, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(b2g18 fixed)

RESOLVED FIXED
Tracking Status
b2g18 --- fixed

People

(Reporter: wlach, Assigned: wlach)

References

Details

Attachments

(1 file, 1 obsolete file)

We still have a mess of internal variables inside DeviceManagerADB. Many of them are initialized in the constructor, where they shouldn't be and also they should be prefixed with an underscore to make it clear that they should not be used outside this class.
There's a few cases in dmSUT that I want to clean up too, expanding scope of bug.
Summary: Clean up internal variables from DeviceManagerADB → Clean up internal variables in mozdevice
I'm pretty sure this shouldn't break anything. I checked for the adb variables in m-c and found they were only used inside dmADB:

wlach@popsicle:~/src/mozilla-central$ for var in haveRootShell haveSu useRunAs useDDCopy useZip logcatNeedsRoot pollingInterval tempDir; do git grep $var; done

testing/mozbase/mozdevice/mozdevice/devicemanagerADB.py:        self.haveRootSh
testing/mozbase/mozdevice/mozdevice/devicemanagerADB.py:        if root and not
testing/mozbase/mozdevice/mozdevice/devicemanagerADB.py:        if root and not
testing/mozbase/mozdevice/mozdevice/devicemanagerADB.py:        if not self.hav
testing/mozbase/mozdevice/mozdevice/devicemanagerADB.py:        if not self.hav
testing/mozbase/mozdevice/mozdevice/devicemanagerADB.py:            self.haveRo

Is there any kind of out-of-tree B2G harness that we should be worried about?
Attachment #679865 - Flags: review?(ahalberstadt)
(In reply to William Lachance (:wlach) from comment #2)
> Created attachment 679865 [details] [diff] [review]
> Clean up internal variable usage in mozdevice
> 
> I'm pretty sure this shouldn't break anything. I checked for the adb
> variables in m-c and found they were only used inside dmADB:
>  ...


Hmm, actually I was wrong there (didn't realize git grep piped the output through less by default). Correcting the command, I see that some of the b2g tests are using this internal variable:

wlach@popsicle:~/src/mozilla-central$ for var in haveRootShell haveSu useRunAs useDDCopy useZip logcatNeedsRoot pollingInterval tempDir; do git grep \.$var; done | cat | grep -v devicemanagerADB | grep b2g.py
layout/tools/reftest/runreftestb2g.py:            if self._devicemanager.useDDCopy:
layout/tools/reftest/runreftestb2g.py:        if self._devicemanager.useDDCopy:
testing/mochitest/runtestsb2g.py:        if self._dm.useDDCopy:

It would actually be quite trivial to refactor this usage to shellCheckOutput (which will magically make them more sut-compatible by default). We should do that if/when we apply the above patch.
Comment on attachment 679865 [details] [diff] [review]
Clean up internal variable usage in mozdevice

Review of attachment 679865 [details] [diff] [review]:
-----------------------------------------------------------------

I know off the top of my head that the reftest and mochitest harness both use at least dmADB.useDDCopy (look at layout/tools/reftest/runreftestb2g.py and testing/mochitest/runtestsb2g.py). There may be other uses of some of the variables in that file as well.

We have reftests and mochitests running on try now too, so I'd also ask for a green try run before pushing this.
Attachment #679865 - Flags: review?(ahalberstadt) → review-
The totally obvious try syntax for the b2g emulator platform is 'ics_armv7a_gecko'
Try run for ac9623e82bfb is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=ac9623e82bfb
Results (out of 30 total builds):
    exception: 20
    success: 2
    warnings: 5
    failure: 3
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/wlachance@mozilla.com-ac9623e82bfb
Try run for 921e2ab136fa is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=921e2ab136fa
Results (out of 30 total builds):
    exception: 3
    success: 17
    warnings: 10
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/wlachance@mozilla.com-921e2ab136fa
(In reply to Andrew Halberstadt [:ahal] from comment #4)
> Comment on attachment 679865 [details] [diff] [review]
> Clean up internal variable usage in mozdevice
> 
> Review of attachment 679865 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I know off the top of my head that the reftest and mochitest harness both
> use at least dmADB.useDDCopy (look at layout/tools/reftest/runreftestb2g.py
> and testing/mochitest/runtestsb2g.py). There may be other uses of some of
> the variables in that file as well.
> 
> We have reftests and mochitests running on try now too, so I'd also ask for
> a green try run before pushing this.

Just got a green try run for B2G (after modifying m-c and my patch a bit):

https://tbpl.mozilla.org/?tree=Try&rev=f2fbef008885

Did an Android run earlier with a few less cleanups that worked well (just ignore the b2g results here):

https://tbpl.mozilla.org/?tree=Try&rev=921e2ab136fa
Here's a new patch (written against m-c) which passes against try (see above).

If it looks ok, I'll push the mozdevice bits to mozbase, bump the version, then merge everything from mozbase in along with the m-c changes to adapt to the new API.
Attachment #679865 - Attachment is obsolete: true
Attachment #680904 - Flags: review?(ahalberstadt)
Comment on attachment 680904 [details] [diff] [review]
Patch with necessary changes made to m-c

Review of attachment 680904 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks! Looks good
Attachment #680904 - Flags: review?(ahalberstadt) → review+
Pushed the mozbase part of things:

https://github.com/mozilla/mozbase/commit/206129578a7686b249af439bcf9852e7b757e8e1

(like I mentioned, I'll include the m-c changes in a merge of mozdevice)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: