956451 - Add configs for debug B2G Mac OS X desktop builds & enable on mozilla-central and mozilla-aurora

Status: RESOLVED DUPLICATE of bug 916111

(Release Engineering :: General, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

It will be good to have a debug version of:

https://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-aurora-macosx64_gecko/

created at:

https://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-aurora-macosx64_gecko-debug/

(for example)

I believe this encompasses only Gaia and Gecko, so it's ok to be public.

It's basically the B2G Desktop version of https://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-aurora-emulator-debug/

This will help speed up fuzzing efforts since B2G desktop should be much faster than the emulator builds.

Comment 1

[Simone Bruno [:simone]]

Hi Gary, I have two questions for you about this:

1. What branches do you want this build to be enabled for?
2. Are there any specific flags you want to enable in the corresponding "mozconfig" file?

Thanks!

Simone

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

For my purposes, at least for mozilla-aurora and mozilla-central, and if it's flags, then probably disable FTU and/or the lockscreen.

However, I'm not the most authoritative on this and other members of the QA / ateam use B2G Desktop for testing more often and I think they *might* be in a better position to advise on this.

Zac, thoughts? (if any, else please feel free to push the needinfo forward)

Comment 3

[Andrew Halberstadt [:ahal]]

Probably at least what is in http://mxr.mozilla.org/mozilla-central/source/b2g/config/mozconfigs/macosx64_gecko/nightly

ENABLE_MARIONETTE=1 is a must.

Comment 4

[Zac C (:zac)]

Gary yes I can't really comment; we'd continue to focus on the user build.

Comment 6

[Simone Bruno [:simone]]

Attachment: b2g_config changes to enable the debug build (WIP)

This is still work in progress, I still need to properly test it on my staging environment.

Comment 7

[Simone Bruno [:simone]]

Attachment: mozconfig file to be used for the debug build

Comment 8

[Simone Bruno [:simone]]

I will submit the patches above for review as soon as I complete some tests in the staging environment.

Comment 9

[Simone Bruno [:simone]]

Attachment: b2g_config changes

Comment 10

[Simone Bruno [:simone]]

Hi catlee,

I discussed this with Aki in the past weeks, but he's not available these days so I am asking you for review.

I am going to also upload changes to add this new build to tbpl.

Thanks!

Simone

Comment 11

[Chris AtLee [:catlee]]

Comment on attachment 8382915 [details] [diff] [review]
b2g_config changes

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

r+ with the unittest_platform fixed.

::: mozilla/b2g_config.py
@@ +270,5 @@
>      },
> +    'macosx64_gecko-debug': {
> +        'product_name': 'b2g',
> +        'app_name': 'b2g',
> +        'unittest_platform': 'macosx64_gecko-opt',

I don't think this is right. Should be 'macosx64_gecko-debug'

Comment 12

[Ed Morley [:emorley]]

Not sure as to the differences between this bug and bug 916111, but there are patches here so not leaving as a dupe.

Seems like best to morph this to be just about enabling B2G OS X desktop debug builds and bug 916111 being about the overall B2G debug story. Adjusting summary and marking blocking that bug - please adjust as appropriate.

Simone - re the email - for these jobs to appear on a debug row in TBPL, they just need to contain the string 'debug' somewhere in the build job name (and at such point where tests are being run too; the test job name) :-)

Comment 13

[Aki Sasaki (not active)]

Simone: what's the status here?

Comment 14

[Simone Bruno [:simone]]

Hi Aki, I've been a bit slow on this :-(

I'll land today the mac-debug related changes, I am now working on the other debug builds (next will be the linux ones).

Comment 15

[Simone Bruno [:simone]]

Just pushed the mac-debug related changes (including the mozconfig file to mozilla-central), the build should be enabled at next reconfig.

Comment 16

[Simone Bruno [:simone]]

Attachment: Bug_956451_fix_ci.diff

After pushing the patch to b2g_config.py, the ci failed with the following message:

AssertionError: <buildbotcustom.scheduler.SpecificNightly-props instance at 0xa921d88> uses unknown builder b2g_mozilla-aurora_macosx64_gecko-debug nightly

http://10.134.48.37:8080/job/buildbot-configs_tests/1872/

This extra patch should fix the problem - catlee, can you confirm this is the right direction? Thanks!

Comment 17

[Ryan VanderMeulen [:RyanVM]]

This was landed on m-c yesterday and the bug wasn't ever marked as such. Please don't forget to do so in the future.
https://hg.mozilla.org/mozilla-central/rev/ccd91b78561f

Also, this is now burning on Aurora due to the patch not landing there yet. I've gone ahead and landed it there as well to hopefully fix the bustage.
https://hg.mozilla.org/releases/mozilla-aurora/rev/4b2caa532478

Comment 18

[Simone Bruno [:simone]]

Thanks Ryan - you are absolutely right... Thanks for landing the aurora part!

Comment 19

[Simone Bruno [:simone]]

Relevant changesets:

http://hg.mozilla.org/build/buildbot-configs/rev/bf42203624c7
http://hg.mozilla.org/build/buildbot-configs/rev/49338c5fb7ef
http://hg.mozilla.org/mozilla-central/rev/ccd91b78561f
http://hg.mozilla.org/releases/mozilla-aurora/rev/4b2caa532478

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Hidden for not meeting visibility standards. They can be unhidden once they're running on all trunk branches.
https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy#3.29_Runs_on_mozilla-central_and_all_trees_that_merge_into_it

Comment 21

[Simone Bruno [:simone]]

Guys, what is the minimal set of branches this should be enabled on in order to comply with the Visibility Rules? I am not able to induce an answer just examining the branches listed in other jobs.

Comment 22

[Aki Sasaki (not active)]

"all the trees that merge into it": I think that means m-c, m-i, b-i, fx-team, try.
https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy#3.29_Runs_on_mozilla-central_and_all_trees_that_merge_into_it

Comment 23

[Phil Ringnalda (:philor)]

"As a rough guide, mozilla-central based trees include mozilla-inbound, fx-team, services-central, ionmonkey, graphics as well as many of the other project/disposable repositories." And don't forget item 5, runs on Try.

There is no minimal set because sheriffs and developers, who wrote that document, very much don't want the minimal set. As a mental experiment, pick your favorite developer that you don't want to disappoint (I usually pick bz), and imagine him working on a twig, a twig that you are desperately trying to not run this job on, for 18 months. He merges his 18 months worth of work to mozilla-central, and burns this build, because you gave him a defective twig which didn't meet the implied promise of "this will tell me what will happen when I merge to m-c."

Now what? If your answer is "well, we hide this build, and work on fixing it" then where to run this is easy: you are not *trying* to create a visible job here, so just run it on whatever branches gkw wants to download builds for, leave it hidden, and make him responsible for filing bugs when it breaks, the same level of support that most of the JS shell builds have.

If instead you are trying to create a build for which any bustage-causing checkin must be immediately backed out, then your answer is in the Visibility_Policy, "and release engineering will enable it in the default config from which all trunk trees inherit (unless the various tree owners have explicitly opted out)." Though since that's aimed at the requester rather than the requestee, it doesn't mention that along with putting it in the default set and removing it just from release branches where you don't want it yet until it follows the trains, you also need to look at twigs with locked platforms, and add it to the ones which would have chosen it if it had existed at the time: Pine, which runs every b2g job, should certainly not be the only twig which does not run a b2g build.

Comment 24

[Simone Bruno [:simone]]

Gary, in the light of Philor's explanation (thanks Philor!), should we keep this enabled (and hidden) on just m-c and aurora (as it currently is), or just enable it on all trunk trees?

Comment 25

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Simone Bruno [:simone] from comment #24)
> Gary, in the light of Philor's explanation (thanks Philor!), should we keep
> this enabled (and hidden) on just m-c and aurora (as it currently is), or
> just enable it on all trunk trees?

I'd go with enabling it on all trunk trees, having it enabled but hidden will not be of much use.

Comment 26

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> having it enabled but hidden will not be of much use.

(especially since no one will likely immediately spot this going orange/red after a patch landing.)

Comment 27

[Simone Bruno [:simone]]

Thanks Gary! I'll submit a patch for that then.

Comment 28

[Simone Bruno [:simone]]

Bug cleanup - For simplicity, I will track progress about this on bug Bug 916111; this is a subset of 916111, in this sense I am marking this as a duplicate.