Closed Bug 717824 Opened 8 years ago Closed 5 years ago

make --with-macbundle-prefix flag for in-tree mozconfigs dependent on the update channel

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(firefox35 fixed, firefox36 fixed)

RESOLVED FIXED
mozilla36
Tracking Status
firefox35 --- fixed
firefox36 --- fixed

People

(Reporter: Gavin, Assigned: Gavin)

Details

Attachments

(1 file, 2 obsolete files)

Bug 696436 added a configure flag that allows us to add a prefix to the Mac bundle filename produced by the build system. This flag was meant to be used to have MoCo-produced Nightly and Aurora builds be FirefoxNightly.app and FirefoxAurora.app, respectively. I did this initially by landing the relevant changes to the in-tree mozconfigs, which works well enough, but there's one downside: the "nightly" mozconfig is also used for nightly builds from the mozilla-beta and mozilla-release repos, which results in odd bundle names for those builds (eg. FirefoxFirefoxDebug or FirefoxFirefox).

This isn't disastrous, since those builds don't get shipped to anyone, but it confuses people who download them manually to test (e.g. in bug 659552).

To avoid this problem, it would be nice if we used the mechanism Armen created in bug 712115 to specify this flag in the releng configs, rather than the in-tree mozconfigs. We really do want them only to be used for MoCo-produced builds, and only for certain branches.
Attached patch config.py changes (obsolete) — Splinter Review
I tried to take a stab in the dark at what these changes might look like, based on the patches in bug 712115. I have no idea if this is correct/sufficient, and it's certainly not tested :)
Summary: add --with-macbundle-name flag to MoCo-produced Nightly/Aurora builds → add --with-macbundle-prefix flag to MoCo-produced Nightly/Aurora builds
Summary: add --with-macbundle-prefix flag to MoCo-produced Nightly/Aurora builds → add --with-macbundle-prefix flag to MoCo-produced Nightly/Aurora Mac builds
I'm -0 on this approach, since it adds yet another special flag in that code and opens the door for lots of other per-branch customization in buildbot-configs which we're actively trying to get away from.

Is this possible to do in the mozconfig?

if [ "${MOZ_UPDATE_CHANNEL}" = "nightly" ]; then
ac_add_options --with-macbundle-prefix
fi

or 

test -f mozconfig-${MOZ_UPDATE_CHANNEL} && . mozconfig-${MOZ_UPDATE_CHANNEL}
(In reply to Chris AtLee [:catlee] from comment #3)
> Is this possible to do in the mozconfig?
> 
> if [ "${MOZ_UPDATE_CHANNEL}" = "nightly" ]; then
> ac_add_options --with-macbundle-prefix
> fi

Yeah, I suppose that could work.

(I suggested the config-hackery only because this is a little different than most build-config changes; we really do only want this to apply to MoCo build infra, since it involves use of the Firefox trademark that would be unauthorized for third parties.)
If we're doing the mozconfig changes, that makes this a Firefox: Build Config bug.
Component: Release Engineering → Build Config
Product: mozilla.org → Firefox
QA Contact: release → build.config
Version: other → unspecified
The other option here would be to back it out of mozilla-beta & release, and make sure we never merge it over again, wouldn't it?
"making sure we never merge it" seems difficult and error-prone, I'll try the mozconfig changes.
Summary: add --with-macbundle-prefix flag to MoCo-produced Nightly/Aurora Mac builds → make --with-macbundle-prefix flag for in-tree mozconfigs dependent on the update channel
Target Milestone: --- → Firefox 13
Version: unspecified → Trunk
Attached patch mozconfig patchSplinter Review
This should have the desired effect, I think, and maintain current behavior. I have no idea how I could actually test this, though, short of landing it... Any suggestions there?
Assignee: nobody → gavin.sharp
Attachment #588267 - Attachment is obsolete: true
Attachment #588268 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8514685 - Flags: review?(catlee)
Attachment #8514685 - Flags: review?(bhearsum)
./mach python build/compare-mozconfig/compare-mozconfigs-wrapper.py passes locally with that patch, so at least that part was tested.
Comment on attachment 8514685 [details] [diff] [review]
mozconfig patch

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

You could push to try with this + hardcoding MOZ_UPDATE_CHANNEL to different things to test this, I think...
Attachment #8514685 - Flags: review?(bhearsum) → review+
Comment on attachment 8514685 [details] [diff] [review]
mozconfig patch

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

looks ok to me. the whitelist changes look a bit odd, but they usually do.
Attachment #8514685 - Flags: review?(catlee) → review+
Pushed to try with the MOZ_UPDATE_CHANNEL hardcoded in the mozconfig:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=a7fc3bb0b789 ("beta")
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=7f8624fbb0df ("nightly")

The compare-mozconfigs failed for all of those because I didn't updated the whitelist, but the "beta" builds didn't get the prefix, and the "nightly" builds did, so I think this is good to go.
Comment on attachment 8514685 [details] [diff] [review]
mozconfig patch

Going to take this on Aurora to simplify bug 1090324.
Attachment #8514685 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/c4a1fa5d2cf4
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Flags: qe-verify-
Component: Build Config → General
Product: Firefox → Firefox Build System
Target Milestone: Firefox 36 → mozilla36
You need to log in before you can comment on or make changes to this bug.