Closed Bug 795028 Opened 9 years ago Closed 9 years ago

update sut_tools to use modern devicemanager

Categories

(Release Engineering :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jmaher, Assigned: jmaher)

References

Details

Attachments

(1 file, 2 obsolete files)

devicemanager has gone through years of development and now lives in mozdevice.
oh yeah, this is the stuff we have all been waiting for.
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #665542 - Flags: review?(bugspam.Callek)
Blocks: 781341
Comment on attachment 665542 [details] [diff] [review]
add devicemanager to suttools (1.0)

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

As said elsewhere, we can't do this without updating clientproxy.py as well (since it uses sut_lib.py) and I don't want to have two instances of mozdevice scripts being used by the same python.

Other than that, and what I listed below this looks pretty good overall.

::: sut_tools/cleanup.py
@@ +77,2 @@
>              data = "127.0.0.1 localhost"
> +            dm._runCmds([{'cmd': 'push /mnt/sdcard/hosts ' + str(len(data)) + '\r\n', 'data': data}])

don't we need to drop the addition of data into the cmd itself? + elsewhere

Or am I misunderstanding what SUTAgent needs here.
Attachment #665542 - Flags: review?(bugspam.Callek) → review-
I have looked at clientproxy.py 3 times now and I cannot find where it uses devicemanager.  Maybe I am looking at the wrong branch of it.  There are no calls to devicemanager or imports of it inside the clientproxy code that I have from the tip of sut_tools.

Regarding the use of _runCmds, the data needs to be in a separate field in the structure we pass in, this was redesigned a while ago to make it more robust inside of devicemanager.
(In reply to Joel Maher (:jmaher) from comment #3)
> I have looked at clientproxy.py 3 times now and I cannot find where it uses
> devicemanager.  Maybe I am looking at the wrong branch of it.  There are no
> calls to devicemanager or imports of it inside the clientproxy code that I
> have from the tip of sut_tools.

Grr (to me) I was remembering we interacted with SUTAgent directly, but forgetting that we had *anything* in sut_tools using the socket directly [e.g. http://mxr.mozilla.org/build/source/tools/sut_tools/clientproxy.py#224]

> Regarding the use of _runCmds, the data needs to be in a separate field in
> the structure we pass in, this was redesigned a while ago to make it more
> robust inside of devicemanager.

But do we still need to pass it as part of the command itself, such that we have

[{'cmd': "foo %(data)s" %foo, 'data': data}] ?
Comment on attachment 665542 [details] [diff] [review]
add devicemanager to suttools (1.0)

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

Ok, reverting previous r- [still need to test before we land!]

This looks good, see previous comment for my realization re: clientproxy and my outstanding Q about "data"

Still needs devicemanager changing [but not blocking this patch]
* http://mxr.mozilla.org/build/source/tools/sut_tools/config.py

Using devicemanager, but obsolete afaict:
* http://mxr.mozilla.org/build/source/tools/sut_tools/installTests.py
Attachment #665542 - Flags: review- → review+
updated to adjust config.py and installTests.py
Attachment #665542 - Attachment is obsolete: true
Attachment #666589 - Flags: review+
Blocks: 797697
updated for issues found during staging
Attachment #666589 - Attachment is obsolete: true
Attachment #667986 - Flags: review+
http://hg.mozilla.org/build/tools/rev/e3f0628bdf89
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.