851278 - Hoststubtest and packstubtest apps are visibile in the production environment build.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/8e9dd87b4f3b
Gaia   69dbcd84085f10bec0c0189b926ffb535b14dcfe
BuildID 20130314114915
Version 18.0

1. flash device with today's build

Expected: no test apps
Actual: test apps in production build

Comment 1

[[:fabrice] Fabrice Desré]

Myk, what lead to that? that's annoying mostly because they show up in nightly updates now.

Comment 2

[[:fabrice] Fabrice Desré]

John, can we switch off the "DOGFOOD" flag for nightlies?

Comment 3

[Myk Melez [:myk] [@mykmelez]]

(In reply to Fabrice Desré [:fabrice] from comment #1)
> Myk, what lead to that? that's annoying mostly because they show up in
> nightly updates now.

We added these to dogfood builds in January to get testing by our dogfooders, but they didn't actually show up until recently, although I'm not sure why.

I'd still like to get more testing of the stub update experience, but it seems unwarranted to show these apps to those users at this point.  It would be better to engage in some targeted testing with QA and turn off these test apps for dogfood/nightly builds (while keeping them enabled for builds that include test apps).

Comment 4

[John Ford [:jhford] CET/CEST Berlin Time]

Attachment: stop setting DOGFOOD=1 in production environment

I don't have an environment to test this, but this should be a trivial patch.

Comment 5

[Aki Sasaki (not active)]

Comment on attachment 725608 [details] [diff] [review]
stop setting DOGFOOD=1 in production environment

This effectively backs out bug 840609, which we had significant pressure to land.

Sounds like we have a communication breakdown here.

Comment 6

[Jason Smith [:jsmith]]

The more I'm digging into this problem, the more I'm thinking the problem is actually having to do with the external-dogfood-apps directory and those apps specifically, rather than generally setting the DOGFOOD=1 flag. If you build an engineering build, you will not get the stubs, although I would have expected to see them.

Comment 7

[[:fabrice] Fabrice Desré]

external-dogfood-apps should be in anytime DOGFOOD=1 (see https://github.com/mozilla-b2g/gaia/blob/master/build/utils.js#L178)

Would moving them to "test" apps make everyone happy? (I would be)

Comment 8

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #7)
> external-dogfood-apps should be in anytime DOGFOOD=1 (see
> https://github.com/mozilla-b2g/gaia/blob/master/build/utils.js#L178)
> 
> Would moving them to "test" apps make everyone happy? (I would be)

Yeah, that works.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Attachment: move test stub apps to test-specific dir

(In reply to Jason Smith [:jsmith] from comment #8)
> (In reply to Fabrice Desré [:fabrice] from comment #7)
> > external-dogfood-apps should be in anytime DOGFOOD=1 (see
> > https://github.com/mozilla-b2g/gaia/blob/master/build/utils.js#L178)
> > 
> > Would moving them to "test" apps make everyone happy? (I would be)
> 
> Yeah, that works.

Ok, here's a change that does that.  All it does is move the files from external-dogfood-apps/ to test_external_apps/, which causes the build system to build them only when the DOGFOOD and PRODUCTION variables are set to '0' in build/utils.js.

Fabrice: if this looks good, merge it via pull request 8706 <https://github.com/mozilla-b2g/gaia/pull/8706>.

Comment 10

[[:fabrice] Fabrice Desré]

Marking leo? since that blocks getting nightlies and they are build off v1-train

Comment 11

[[:fabrice] Fabrice Desré]

Comment on attachment 726219 [details] [diff] [review]
move test stub apps to test-specific dir

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

Thanks!

Comment 12

[[:fabrice] Fabrice Desré]

Pushed to master: https://github.com/mozilla-b2g/gaia/commit/73f407d356db424dd689543a6cacee5b36861a42

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Attachment: followup to fix build failures

Associated pull request:

https://github.com/mozilla-b2g/gaia/pull/8707

Comment 14

[[:fabrice] Fabrice Desré]

https://github.com/mozilla-b2g/gaia/commit/fc6fa694cbe2ac792db1fb756824228c1b6682be

Comment 15

[Ed Morley [:emorley]]

This broke B2G builds on all trees (which are now closed as a result). Please can this be backed out.

eg:
https://tbpl.mozilla.org/php/getParsedLog.php?id=20785230&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=20785293&tree=Mozilla-Inbound

Please can you also watch https://tbpl.mozilla.org/?tree=Gaia-Master when landing on gaia to more easily spot gaia commit induced failures (that break all trees and make the sheriffs sad). Thank you :-)

Comment 16

[Ed Morley [:emorley]]

s/all trees/all trees that use gaia master/

Comment 17

[Chris Lee [:clee]]

This is a blocker for product and press.  Thanks.

Comment 18

[Ed Morley [:emorley]]

Ping for someone to back this out please.

Comment 19

[[:fabrice] Fabrice Desré]

(In reply to Ed Morley [:edmorley UTC+0] from comment #18)
> Ping for someone to back this out please.

We pushed a followup and that looks ok at https://tbpl.mozilla.org/?tree=Gaia-Master

Comment 20

[Ed Morley [:emorley]]

Oh I didn't realise - though we'll still likely need to wait for it to come back green (it's not finished). For future occasions, please can you comment in the bug if you land a followup for things that are keeping the tree closed - thank you :-)

Comment 21

[Myk Melez [:myk] [@mykmelez]]

https://tbpl.mozilla.org/?tree=Gaia-Master is now back to green.

Comment 22

[Ed Morley [:emorley]]

Thank you :-)

Comment 23

[John Ford [:jhford] CET/CEST Berlin Time]

Squashed commits into 2b594f6587dd9c4a7cca8c9cd59325c4eb2fedf1 on v1-train

Comment 24

[Jason Smith [:jsmith]]

Verified on 3/19 build - no longer seeing these apps in daily builds on v1 train.