Closed Bug 1214528 Opened 9 years ago Closed 9 years ago

Autophone - Talos tests fail with no measurements

Categories

(Testing Graveyard :: Autophone, defect)

defect
Not set
normal

Tracking

(firefox44 affected)

RESOLVED FIXED
Tracking Status
firefox44 --- affected

People

(Reporter: bc, Assigned: jmaher)

References

Details

(Whiteboard: [fixed-by-bug-1216636])

When we deployed Talos tp4m and tsvg we ran into problems where the tests were perma red due to failures to detect measurements.

The proximate cause was the tp4m.manifest.develop and svgm.manifest.develop files were not being pushed to the devices even though the tp4m.manifest and svgm.manifest files were.
Depends on: 1214530
While investigating possible fixes for the failure to get measurements, I realized that Autophone's code worked properly here locally and for jmaher but did not work on the Autophone mac mini host. It seemed to be a problem with adb push not pushing the full contents of the source directory to the destination directory. For some reason the *.manifest.develop files were not being pushed even though some/most of the other files were being pushed.

In an attempt to resolve this, I updated android tools including adb. Although adb still reports its version as 1.0.32 it contains a number of changes. Once of the changes is that if you use wait-for-device more than once in a command it will be treated as a syntax error. This caused bug 1214530.

I deployed a patch for bug 1214530 as a hot fix on Autophone and it resolved the adb syntax issue and the failure to copy the *.manifest.develop files.
Android Platform Tools 23.0.1's adb was very problematic as it would continually disconnect due to
adb server is out of date.  killing...

errors. I also tried 23.1 rc1 however this caused the tests to run much slower due to repeated disconnections with messages like 

adb I 74926 1204278 usb_osx.cpp:259] 
adb E 74926 1204278 usb_osx.cpp:331] Could not open interface: e00002c5
adb E 74926 1204278 usb_osx.cpp:265] Could not find device interface
adb I 74926 1204278 usb_osx.cpp:259] Found vid=18d1 pid=4ee2 serial=07c0feac2581ad6e

I've reverted to the Android Platform Tools 21's adb which appears to be working well so far.
so our problem is adb pushing files, can we just retry for the talos stuff until we get linux servers?  should we leave a static copy of bits on the device?
I'm not sure I understand.

Q: can we just retry for the talos stuff until we get linux servers?

Do you mean just keep running it and having it continually fail? I don't see the point in that. Perhaps we can work around the push issue or find a root cause for it. But yes, hopefully Linux is our salavation.

Q: should we leave a static copy of bits on the device?

bits of what? adb? I have a static copy of it on autophone and here locally in case I need to restore it. Is that what you mean?
oh, the ambiguous communication that I have a problem with!  let me clarify:

* can we retry pushing files to the device, maybe per file and validate it better
* a static copy of the test info, specifically the manifest.  as we have a single device, it would probably work.


This assumes that running a newer version of android tools on the linux server will solve the problem.
(In reply to Joel Maher (:jmaher) from comment #5)
> oh, the ambiguous communication that I have a problem with!  let me clarify:
> 
> * can we retry pushing files to the device, maybe per file and validate it
> better

Yes. I was thinking we could work around whatever this issue is and making sure the files are all pushed. In the old days, devicemanager did things like pushing a zip file and unzipping it on the device. I'm sure we can work around the problem giving some time to experiment. That is one reason I wanted to keep the talos jobs available via try.

> * a static copy of the test info, specifically the manifest.  as we have a
> single device, it would probably work.
> 

If we work around the pushing problem, I don't think we need worry about this per se.

> 
> This assumes that running a newer version of android tools on the linux
> server will solve the problem.

Not sure I follow. Hopefully Linux's version of the new adb doesn't suffer from the same problems as the OSX version which in that event the pushing problems would go away anyway. I'll have to upgrade my version here to check that out. /me crosses fingers.
Blocks: 1170685
jmaher found and fixed the issue in bug 1216636
Assignee: bob → jmaher
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-by-bug-1216636]
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.