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

RESOLVED DUPLICATE of bug 916111

Status

defect
RESOLVED DUPLICATE of bug 916111
5 years ago
a year ago

People

(Reporter: gkw, Assigned: sbruno)

Tracking

unspecified

Firefox Tracking Flags

(firefox30 fixed, firefox31 fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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.
Component: General → General Automation
Product: Firefox OS → Release Engineering
QA Contact: catlee
(Assignee)

Updated

5 years ago
Summary: Create debug B2G desktop builds on tinderbox → Create debug B2G desktop builds
(Assignee)

Updated

5 years ago
Assignee: nobody → sbruno
(Assignee)

Comment 1

5 years ago
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
Flags: needinfo?(gary)
(Reporter)

Comment 2

5 years ago
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)
Flags: needinfo?(gary) → needinfo?(zcampbell)

Comment 4

5 years ago
Gary yes I can't really comment; we'd continue to focus on the user build.
Flags: needinfo?(zcampbell)
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 916111
(Reporter)

Updated

5 years ago
No longer blocks: marifuzz
(Assignee)

Comment 6

5 years ago
This is still work in progress, I still need to properly test it on my staging environment.
(Assignee)

Comment 8

5 years ago
I will submit the patches above for review as soon as I complete some tests in the staging environment.
(Assignee)

Updated

5 years ago
(Assignee)

Comment 9

5 years ago
Attachment #8363594 - Attachment is obsolete: true
Attachment #8382915 - Flags: review?(catlee)
(Assignee)

Updated

5 years ago
Attachment #8363595 - Attachment description: mozconfig file to be used for the debug build - WIP → mozconfig file to be used for the debug build
Attachment #8363595 - Attachment filename: 956451_WIP_mozconfig_debug → 956451_mozconfig_debug
Attachment #8363595 - Attachment is patch: true
Attachment #8363595 - Flags: review?(catlee)
(Assignee)

Comment 10

5 years ago
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 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'
Attachment #8382915 - Flags: review?(catlee) → review+
Attachment #8363595 - Attachment is patch: false
Attachment #8363595 - Flags: review?(catlee) → review+
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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) :-)
Blocks: 916111
No longer blocks: bld-lion-r5-087
Status: REOPENED → ASSIGNED
Summary: Create debug B2G desktop builds → Add configs for debug B2G desktop builds & enable on mozilla-central and mozilla-aurora
Simone: what's the status here?
Flags: needinfo?(sbruno)
(Assignee)

Comment 14

5 years ago
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).
Flags: needinfo?(sbruno)
(Assignee)

Comment 15

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

Comment 16

5 years ago
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!
Attachment #8399578 - Flags: review?(catlee)
Attachment #8399578 - Flags: review?(catlee) → review+
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
Flags: needinfo?(sbruno)
(Assignee)

Comment 18

5 years ago
Thanks Ryan - you are absolutely right... Thanks for landing the aurora part!
Flags: needinfo?(sbruno)
(Assignee)

Updated

5 years ago
Attachment #8363595 - Flags: checked-in+
(Assignee)

Updated

5 years ago
Attachment #8382915 - Flags: checked-in+
(Assignee)

Updated

5 years ago
Attachment #8399578 - Flags: checked-in+
(Assignee)

Comment 19

5 years ago
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
Summary: Add configs for debug B2G desktop builds & enable on mozilla-central and mozilla-aurora → Add configs for debug B2G Mac OS X desktop builds & enable on mozilla-central and mozilla-aurora
(Assignee)

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
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
(Assignee)

Updated

5 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 21

5 years ago
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.
Flags: needinfo?(catlee)
Flags: needinfo?(aki)
"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
Flags: needinfo?(aki)
(Assignee)

Updated

5 years ago
Flags: needinfo?(catlee)
"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.
(Assignee)

Comment 24

5 years ago
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?
Flags: needinfo?(gary)
(Reporter)

Comment 25

5 years ago
(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.
Flags: needinfo?(gary) → needinfo?(sbruno)
(Reporter)

Comment 26

5 years ago
> 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.)
(Assignee)

Comment 27

5 years ago
Thanks Gary! I'll submit a patch for that then.
Flags: needinfo?(sbruno)
(Assignee)

Comment 28

5 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 916111
(Assignee)

Updated

5 years ago
No longer blocks: 916111
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.