553352 - check in sutagent

Status: RESOLVED WONTFIX

(Testing :: General, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

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

Comment 2

[cmtalbert]

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.

Comment 3

[(not currently active) Ted Mielczarek]

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

[cmtalbert]

Attachment: 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

[cmtalbert]

(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...

Comment 6

[(not currently active) Ted Mielczarek]

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

[cmtalbert]

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

[Aki Sasaki (not active)]

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|.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

(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

[Aki Sasaki (not active)]

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

Comment 11

[cmtalbert]

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

WFM too

Comment 12

[William Lachance (:wlach)]

Can we resolve/close this bug? It doesn't seem to be relevant any more.

Comment 13

[Joel Maher ( :jmaher ) (UTC -8)]

I am fine closing this.

Comment 14

[Bob Moss :bmoss]

The wince agent is no longer relevant and the Android agent is checked into the tree. So closing this bug.