Closed Bug 921180 Opened 6 years ago Closed 6 years ago

B2G desktop mochitest runner strips '-b2g' from the appname

Categories

(Testing :: Mochitest, defect)

All
Linux
defect
Not set

Tracking

(firefox28 fixed, b2g-v1.2 fixed)

RESOLVED FIXED
mozilla27
Tracking Status
firefox28 --- fixed
b2g-v1.2 --- fixed

People

(Reporter: ahal, Assigned: jgriffin)

References

Details

Attachments

(1 file)

Error: http://pastebin.mozilla.org/3152269

The "TypeError: container is null" happens when the test gaia apps aren't installed. In the past this has happened from a build configuration that excludes them (such as setting PRODUCTION=1).

In this case I don't know what is causing them to not be available. All I know is that I can get them to run with a local b2g desktop build, but not with a build downloaded from tinderbox (note: this is using the same gaia profile for both).

For the record my local mozconfig: http://pastebin.mozilla.org/3152271
Production mozconfig (I think): http://mxr.mozilla.org/mozilla-central/source/b2g/config/mozconfigs/linux64_gecko/nightly

Aki or catlee, do either of you see anything in the production mozconfig that would cause the gaia test apps to be unavailable?
Flags: needinfo?(catlee)
Flags: needinfo?(aki)
It might be part of MOZILLA_OFFICIAL, but b2g devs probably know more.
Flags: needinfo?(aki)
Some extra data points..

- If I ctrl-f for 'test-container' in the b2g desktop build log, there *are no* results.
- If I ctrl-f for 'test-container' in the b2g emulator build log, there *are* results.
- For some reason that is incomprehensible to me, the gaia profile that is packaged alongside the b2g desktop build *does* contain the test-container app (which explains why the profile works with my local build). The downloaded gecko build just seems to ignore it.
(In reply to Aki Sasaki [:aki] from comment #1)
> It might be part of MOZILLA_OFFICIAL, but b2g devs probably know more.

Yeah that might be it, the ics_armv7a_gecko mozconfig doesn't have that set. If we get the mozharness patch landed and the jobs scheduled on Cedar, I'll be able to more easily try playing around with the mozconfig to see what happens.
Blocks: 916127
Flags: needinfo?(catlee)
I tried disabling MOZ_OFFICIAL=1 on Cedar, we'll see how that turns out.

https://tbpl.mozilla.org/?tree=Cedar&rev=34def15b58b9
That didn't seem to fix anything. Either MOZILLA_OFFICIAL=1 has no affect, or they aren't using those mozconfigs. I'll try to play around with the builds locally a bit more. Jonathan, do you see anything in these mozconfigs [1] that might cause the "container is null" error (i.e test apps not being packaged)?

[1] http://mxr.mozilla.org/mozilla-central/source/b2g/config/mozconfigs/linux64_gecko/nightly
Flags: needinfo?(jgriffin)
I noticed from the mozconfig.common import, --enable-release is set. New cedar run to test disabling it:
https://tbpl.mozilla.org/?tree=Cedar&rev=f104dd20fbb1
This seems to affect any build that's made with GAIADIR in the mozconfig, and is not related to the specific gaia profile used; I can reproduce it locally with a GAIDIR build regardless of how I create my gaia profile.  I'm not sure why this occurs, however.
Flags: needinfo?(jgriffin)
With hg blame, looks like the use of a built-in gaia profile is from bug 776783. I imagine we either want to make that built-in profile use test apps, or probably better, just have a separate mozconfig for non-nightly builds that doesn't include the GAIADIR variable.

The motivation seems to be that QA wanted an easier set up process, but the drawback is that you are forced into using a specific profile that is built with the application. I think most b2g devs will want to have the ability to specify their own profiles into downloaded builds. Tony, would having nightly builds use the pre-built profile and normal builds not be an acceptable compromise?
Flags: needinfo?(tchung)
(In reply to Andrew Halberstadt [:ahal] from comment #8)
> With hg blame, looks like the use of a built-in gaia profile is from bug
> 776783. I imagine we either want to make that built-in profile use test
> apps, or probably better, just have a separate mozconfig for non-nightly
> builds that doesn't include the GAIADIR variable.
> 
> The motivation seems to be that QA wanted an easier set up process, but the
> drawback is that you are forced into using a specific profile that is built
> with the application. I think most b2g devs will want to have the ability to
> specify their own profiles into downloaded builds. Tony, would having
> nightly builds use the pre-built profile and normal builds not be an
> acceptable compromise?

I'm not clear from reading this bug if the Device builds from releng will be affected.   I'm most interested if i can still flash builds from pvtbuilds on device, and still see a profile with production apps.   The engineering builds from pvtbuilds also need to continue to be flashed and load engineering apps in the list.

Does your proposal break the above?
Flags: needinfo?(tchung)
(In reply to Tony Chung [:tchung] from comment #9)
> I'm not clear from reading this bug if the Device builds from releng will be
> affected.   I'm most interested if i can still flash builds from pvtbuilds
> on device, and still see a profile with production apps.   The engineering
> builds from pvtbuilds also need to continue to be flashed and load
> engineering apps in the list.
> 
> Does your proposal break the above?

No, my proposal is to stop bundling the profile for non-nightly b2g_desktop builds (a.k.a the ones here: http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-inbound-linux64_gecko). B2G device builds would be unaffected.

I just wanted to check with you first because you filed bug 776783 (over a year ago) and I wasn't sure how this special built-in profile is getting used for b2g_desktop these days (if at all).
Wait this, might just be the whole "b2g-bin" vs "b2g" problem.. Just noticed we are using "b2g". I re-triggered the job from the latest ash run: https://tbpl.mozilla.org/?tree=Ash&rev=c49e41aa05bb
Still broken, ignore comment 11 :)
Yeah, I've reproduced this using local builds, and running the command-line myself with b2g-bin. :(
This is due to a bug in mozrunner, I think.  Even when passing --app /path/to/b2g-bin, what mozrunner actually ends up launching is /path/to/b2g.  Debugging...
No, it's a bug in runtestsb2g.py.  Patch incoming.
Attachment #815457 - Flags: review?(ahalberstadt)
Assignee: nobody → jgriffin
Comment on attachment 815457 [details] [diff] [review]
Use b2g-bin if it exists,

Review of attachment 815457 [details] [diff] [review]:
-----------------------------------------------------------------

Oh wow. Good catch!

I guess this makes the patch in bug 925375 redundant.

::: testing/mochitest/runtestsb2g.py
@@ +345,3 @@
>      mochitest = B2GDesktopMochitest(marionette, options.profile_data_dir)
>  
>      # b2g desktop builds don't always have a b2g-bin file

nit: update comment since we are now adding '-bin' instead of removing it
Attachment #815457 - Flags: review?(ahalberstadt) → review+
(In reply to Andrew Halberstadt [:ahal] from comment #10)
> (In reply to Tony Chung [:tchung] from comment #9)
> > I'm not clear from reading this bug if the Device builds from releng will be
> > affected.   I'm most interested if i can still flash builds from pvtbuilds
> > on device, and still see a profile with production apps.   The engineering
> > builds from pvtbuilds also need to continue to be flashed and load
> > engineering apps in the list.
> > 
> > Does your proposal break the above?
> 
> No, my proposal is to stop bundling the profile for non-nightly b2g_desktop
> builds (a.k.a the ones here:
> http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-inbound-
> linux64_gecko). B2G device builds would be unaffected.
> 
> I just wanted to check with you first because you filed bug 776783 (over a
> year ago) and I wasn't sure how this special built-in profile is getting
> used for b2g_desktop these days (if at all).

ah okay. i havent been working with desktop builds in the last year so this doesnt apply to me anymore.  thanks for calling that out!
I pushed jgriffin's patch to ash and I see orange! Morphing bug.
Status: NEW → ASSIGNED
Component: General Automation → Mochitest
Product: Release Engineering → Testing
QA Contact: catlee
Summary: Can't run b2g desktop mochitests on releng builds → B2G desktop mochitest runner strips '-b2g' from the appname
https://hg.mozilla.org/mozilla-central/rev/de4adb31aeb6
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
I uplifted this to mozilla-b2g26 as it was causing bustage for the newly enabled b2g desktop mochitests:
https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/a91df191b189
You need to log in before you can comment on or make changes to this bug.