Status

Testing
New Frameworks
RESOLVED WONTFIX
8 years ago
6 years ago

People

(Reporter: jmaher, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
We have this great tool sutagent.exe which acts as the core of our windows mobile testing, but right now it is not easy for anybody to get the source and build it.

We should check it into mozilla-central/build/wince/sutagent/

Ideally we would be able to build with when doing a wince/winmo build, so the sutagent.exe would be available to developers.
(Reporter)

Comment 1

8 years ago
Currently this is located at: http://bitbucket.org/ctalbert/orodruin/src/tip/sutAgent/

Comment 2

8 years ago
So, I'd like to check in the sutagent code into build/wince/sutagent but I don't really see any benefit in doing all the makefile tooling to get it to build given that we've moved on to android.  I think this code is useful to have around as a reference though because I envision us writing more of these agents, and this one should be considered the standard in terms of functionality that it provides because it is compatible with the rest of the remote testing solution.

So, anyone object to landing the code in m-c without a makefile (in other words, the directory would be entirely skipped during make, which is effectively what would happen anyway unless we were building winmo).

This code is based on the code from blassey's user repo, but with the following major changes:
* UI is implemented
* Networking is handled
* Power information is provided
* Unzip command added/completed
* Bug fixes

So, does anyone have any objections to landing this? Does it need to be reviewed?

BTW, stylistically this copy of the code is a mess - CRLF's, a mix of tabs and spaces for indenting, no MPLs.  I'm going to pull the code over from my windows box and clean up tabs -> spaces, insert MPLs with Blassey and Bmoss as contributors and make everything end in LF before attaching a patch.
If it's just for reference, I don't see why sticking it in mozilla-central makes much sense. I think another repo on hg.mozilla.org would be fine. It's just going to be one more thing lost in the clutter in m-c.

Comment 4

8 years ago
Created attachment 434609 [details] [diff] [review]
Basic code for SUTAgent

Here is a set of code.  Added in the MPLs where appropriate (i.e. not on microsoft files) and changed all tabs to spaces, all CRLFs to LFs.

We were building this thing directly from visual studio, so I have the solution and project files in here to make returning to that world easier.

Comment 5

8 years ago
(In reply to comment #3)
> If it's just for reference, I don't see why sticking it in mozilla-central
> makes much sense. I think another repo on hg.mozilla.org would be fine. It's
> just going to be one more thing lost in the clutter in m-c.
That's a good idea, and I'm all for it.

What about the other agents, for instance the Android agent.  Should I create a repo on hg.mozilla.org to house them all?  Or should the ones we're using actually be in m-c?  

In my opinion, we don't gain much by putting these agents in m-c because there is no automatic way to "beam" the agent onto the phone for automation.  That has to be done by hand when the phone is set up for inclusion into automation.

The one thing we would gain by putting the agent code into m-c is that it would be available in the bin directory when you did a "make package-tests" for a mobile build.  Like I said, we can't really use that from an automation standpoint though, so I'm on the fence about whether its worth the headache to get it in the tree and building (android sutagent doesn't build inside our make system as it pre-dates the our make system's android support).

Thoughts on that?  I'm leaning toward something like hg.mozilla.org/sutagents/winmo hg.mozilla.org/sutagents/android etc...
If they're actually being used then I don't have a problem with having them in-tree, although if, as you said, you can't really build them or put them on the device from in-tree, then it probably doesn't buy us anything. Your suggested /sutagents/{platform} sounds like a pretty reasonable storage spot. If they're nice standalone programs with nice standalone build systems (like the vc project), then keeping them in their own repos is probably the best way to go, so a) people don't have to grab all of m-c just to build a test agent, and b) people working in m-c don't have to wonder what these files are doing there.

Comment 7

8 years ago
I'm going to check in the SUTAgent code  for winmo elsewhere, but I'll put the Android code into m-c to make it easy to build for folks wishing to use it.

Comment 8

7 years ago
I'm not entirely certain if we should open a new bug or use this old one.

Aiui, Brad is going to be checking in SUTAgent and the helpers into m-c.
My ask would be that, if it's not too much extra work, we add bug 611648 to the list while we do this.

I think the fix for bug 611648 is to package SUTAgent during |make package|, using the same JARSIGNER as |make package|, instead of during |make build|.
(In reply to comment #8)
> I think the fix for bug 611648 is to package SUTAgent during |make package|,
> using the same JARSIGNER as |make package|, instead of during |make build|.

perhaps |make package-tests|? 99% of the time we don't care about the SUTAgent

Comment 10

7 years ago
Hm, package-tests wfm, as long as JARSIGNER works like in make package.

Comment 11

7 years ago
(In reply to comment #10)
> Hm, package-tests wfm, as long as JARSIGNER works like in make package.

WFM too
Can we resolve/close this bug? It doesn't seem to be relevant any more.
Status: NEW → UNCONFIRMED
Ever confirmed: false
(Reporter)

Comment 13

6 years ago
I am fine closing this.

Comment 14

6 years ago
The wince agent is no longer relevant and the Android agent is checked into the tree. So closing this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.