Closed Bug 1049202 Opened 6 years ago Closed 6 years ago

automationutils fakes mozinfo


(Testing :: Mochitest, defect)

Not set


(Not tracked)



(Reporter: gps, Assigned: ted)




(1 file)

Bug 1038943 added code to to check['toolkit']. This resulted in a KeyError due to 'toolkit' not being present.

I downloaded the tests zip archive ( and examined the mozinfo.json file:

$ python -mjson.tool mochitest/mozinfo.json
    "appname": "fennec",
    "asan": false,
    "bin_suffix": "",
    "bits": 32,
    "buildapp": "mobile/android",
    "crashreporter": true,
    "datareporting": true,
    "debug": false,
    "healthreport": true,
    "mozconfig": "/builds/slave/b2g-in-and-0000000000000000000/build/.mozconfig",
    "os": "android",
    "processor": "arm",
    "tests_enabled": true,
    "toolkit": "android",
    "topsrcdir": "/builds/slave/b2g-in-and-0000000000000000000/build",
    "wave": true,
    "webm": true

Since mozinfo.json doesn't populate info['toolkit'] by default, I suspect the problem is that find_and_update_from_json() isn't being called from automation and/or that the mozinfo.json from the tests zip is not being loaded.

I'm pretty sure this is a regression - and a serious one at that, since automation is no longer respecting our build configs :/
I'm not sure if this ever worked. We attempt to import mozbuild in the "load mozinfo.json" code path and this will never work in automation since mozbuild is not included as part of
That code path is just for running locally. The test harnesses should have logic to find the mozinfo.json in the For example, mochitests do:
I don't think the problem here is that automation isn't respecting our build configs. If you look at the list of skipped tests just before the traceback, they are correctly skipped because 'toolkit == "android"'. So at the very least manifestparser is receiving the correct I'm not sure why isn't.
Yeah, bummer. Wonder if that's still true?
Summary: mozinfo.json isn't being loaded in automation → automationutils fakes mozinfo
I have no idea why mozinfo can't be imported, or if it is still the case. However if we want to continue using this hack, setting toolkit to 'android' would "fix" the immediate problem and let us backout khuey's bustage fix.

(Note: I'm not advocating we do that)
So, last I knew that was a workaround for non-mozharness Android test jobs. I believe that since we've killed tegra tests on trunk we don't have any more of those, and we could probably remove that hack. I'll test that theory.
Try push with that junk removed:
Assignee: nobody → ted
We only take that path if the import fails so that means the import is failing, no?
Yeah, but it's possible we aren't bothering to copy mozbase or setup sys.path because it previously wasn't working.

We need Joel or Geoff to chime in here.
Flags: needinfo?(jmaher)
Flags: needinfo?(gbrown)
Yeah, it's definitely still broken:

"ImportError: No module named mozinfo"ImportError: No module named mozinfo" on the Android 2.3 emulator tests. They're running under mozharness, but it looks like they're not installing the mozbase modules.
From quickly reviewing the mozharness scripts, it looks like PandaTest uses MozbaseMixin:

where AndroidEmulatorTest does not:

I'll file another bug to fix that.
Depends on: 1049739
so it looks as though the panda tests work but only the 2.3 emulator tests fail.  Once that is fixed we could remove this!
Flags: needinfo?(jmaher)
I think we are on the right track here. I just put a patch up for review in bug 1049739.
Flags: needinfo?(gbrown)
Might as well get this reviewed then. This can't land until gbrown's mozharness patch makes it into production.
Attachment #8470057 - Flags: review?(jmaher)
Comment on attachment 8470057 [details] [diff] [review]
remove automationutils mozinfo workaround for non-mozharness Android tests

Review of attachment 8470057 [details] [diff] [review]:

can you verify this on try server?  Are there concerns with b2g here?
Attachment #8470057 - Flags: review?(jmaher) → review+
I pushed it to try this morning after I saw gbrown's patch go into production:

Pretty green!
(In reply to Kyle Huey [:khuey] ( from comment #6)
> When this is fixed
> should be
> reverted.

I forgot to do this, feel free to do that anytime.
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in before you can comment on or make changes to this bug.