Closed
Bug 795028
Opened 12 years ago
Closed 12 years ago
update sut_tools to use modern devicemanager
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jmaher, Assigned: jmaher)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
jmaher
:
review+
|
Details | Diff | Splinter Review |
devicemanager has gone through years of development and now lives in mozdevice.
Assignee | ||
Comment 1•12 years ago
|
||
oh yeah, this is the stuff we have all been waiting for.
Comment 2•12 years ago
|
||
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-
Assignee | ||
Comment 3•12 years ago
|
||
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.
Comment 4•12 years ago
|
||
(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 5•12 years ago
|
||
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+
Assignee | ||
Comment 6•12 years ago
|
||
updated to adjust config.py and installTests.py
Attachment #665542 -
Attachment is obsolete: true
Attachment #666589 -
Flags: review+
Assignee | ||
Comment 7•12 years ago
|
||
updated for issues found during staging
Attachment #666589 -
Attachment is obsolete: true
Attachment #667986 -
Flags: review+
Comment 8•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•