827699 - Android mochitests and talos don't run on Beta 19 builds

Status: RESOLVED FIXED

(Testing :: General, defect)

Description

[Phil Ringnalda (:philor)]

Nobody's been able to figure out why, but since 19 merged to beta, the Android mochitests and talos time out starting up, while the reftests and crashtests and jsreftests succeed. The only apparent difference in the logs is that mochitests and talos pass a URL to open in the commandline, ... org.mozilla.beta http://..., while the reftest harness does not, it just opens org.mozilla.beta and (handwaving) it knows what to load.

Since we've already got several pushes to beta, and people show no sign of stopping just because Android tests aren't actually running, the tree is closed.

Comment 1

[Alex Keybl [:akeybl]]

wesj was looking into this earlier this evening. Any updates Wes?

Comment 2

[Alex Keybl [:akeybl]]

Also including Clint, who should be back tomorrow :), and should be able to help us get some eyes on

Comment 3

[Wesley Johnston (:wesj)]

Nothing interesting to report. I can't reproduce the failures on my devices. I pushed a few things to try to see if this is caused by the version/branding bumps. There are odd things in some of the logs (one mentioned fennec_aurora and one has failures in a lot of reflection methods), but they seem to be semi-random. joduin hinted maybe they were happening in Aurora (but just not being noticed?). I couldn't find them in Aurora builds I checked though. Still poking around looking for a good lead.

Comment 4

[Bob Clary [:bc] (inactive)]

Running the mochitests on beta on my nexus one show a prompt to share my location with google. The test has stalled while waiting for a reply. I assume it will hit the 2400 seconds timeout and be killed like the runs on tbpl. I have not noticed the location sharing prompt before.

Comment 5

[Wesley Johnston (:wesj)]

I noticed Google started asking for geo location on search results yesterday too. I ran (some) mochitests locally and didn't see any prompt here, but maybe I should try running a larger set.

Why would we be loading Google searches during tests? I guess if you pass in a search term as a url we might, but the urls look fine in the logs. And why would that only affect beta...

Comment 6

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

we are not loading our profile, so the url we are loading is '-no-remote -profile /mnt/sdcard/tests http://mochi.test:8888/tests/...' and this translates into a search on google since we load a default profile.

Comment 7

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

Attachment: use the VIEW intent for either fennec or firefox products (1.0)

Comment 8

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

Attachment: use the VIEW intent for either fennec or firefox products (1.1)

fixed an extra parenthesis and bumped the version.  Tested this locally and it works great.

Comment 9

[Alex Keybl [:akeybl]]

Comment on attachment 699251 [details] [diff] [review]
use the VIEW intent for either fennec or firefox products (1.1)

[Triage Comment]
Pre-approving for beta since this is impacting our beta 1 go. Please land asap.

Comment 10

[Wesley Johnston (:wesj)]

Pushed to beta (I changed the version number change slightly?)

https://hg.mozilla.org/releases/mozilla-beta/rev/e7cc9405b1f3

Comment 11

[Alex Keybl [:akeybl]]

Comment on attachment 699251 [details] [diff] [review]
use the VIEW intent for either fennec or firefox products (1.1)

Since this landed on central/beta, assuming this is needed for aurora as well.

Comment 12

[Alex Keybl [:akeybl]]

What still needs to happen here? The talos tests are still busted...

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Alex Keybl [:akeybl] from comment #12)
> What still needs to happen here? The talos tests are still busted...

bug 828021

Comment 14

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

we need to resolve bug 828752 in order to fix the few remaining tests on firefox-beta.

Comment 15

[Phil Ringnalda (:philor)]

Well, that and some sort of miracle to make ts not crash so much (29 out of 31 runs on the tip push), but given how Android is, that's no tree-blocker, and everything else is fine now. Reopened.

Comment 16

[cmtalbert]

This appears to be fixed, is there any other action required here?

Comment 17

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

I assumed a resolved->fixed was all we needed to do.

Comment 18

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

Why is this bugging me about an unlanded aurora 20 bug status?  This has been resolved for weeks.

Comment 19

[Phil Ringnalda (:philor)]

Because it thinks you need to use your approval-aurora on attachment 699251 [details] [diff] [review] by landing it on aurora, so we don't get the exact same thing when 20 merges to beta and starts building firefox instead of fennec.

Comment 20

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

well, it is a sutagent change and that is not related to the branches we run on, so whatever I did for this bug has nothing to do with specific branches.  Is there a way to clear this flag or tell some unknown magical system to ignore this bug?

Comment 21

[Phil Ringnalda (:philor)]

So the in-tree sutagent doesn't do anything, and there wasn't actually any point in landing https://hg.mozilla.org/releases/mozilla-beta/rev/e7cc9405b1f3?

Comment 22

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

correct.  The in tree sutagent is so folks can build on their own if they want it locally.  The SUTAgent is managed as a whole (not per branch) across the tegras and pandas.

Comment 23

[Phil Ringnalda (:philor)]

So if someone builds 19, will they get a working sutagent because it knows about firefox and not just fennec, or will they get a broken non-working sutagent because 1.13 is too old and broken to actually work, even against 19?

If someone builds 20 today, will they get a working sutagent, or is the code that's on aurora right now too old and broken?

And the key question, after we merge 20 to beta, and change the default branding, will someone who is doing exactly the right thing, building just like the tree does with firefox branding, get a broken sutagent because it doesn't know about firefox, and would they get a working sutagent if that attachment landed on aurora and this bug got marked as status-firefox20: fixed?

Comment 24

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

this was only approved for aurora because initially folks thought that the sutagent was branch specific.  If somebody were to build sutagent from Firefox 18 it will have the same problem as well.  I have yet to find a developer who has installed sutagent unless I have specfically asked them to.  If we were to replicate automation, you will see that the sutagent comes from a different location (we don't publish it from the build), and all the other tools used for automation are not branch specific.

Comment 25

[Ed Morley [:emorley]]

The m-c changeset was never pasted in the bug. For posterity:
https://hg.mozilla.org/mozilla-central/rev/2ac1e848a23d