Closed Bug 1152031 Opened 6 years ago Closed 5 years ago

Disable universal builds by default on OSX, enable for nightlies only

Categories

(Release Engineering :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: catlee, Unassigned)

Details

Attachments

(2 files)

Our per-build builds on OSX shouldn't be unified by default, it just wastes a lot of time.

We assume that risk of bustage in the unification process is minimal, so we'll have the regular nightlies be universal.
Assignee: nobody → mshal
I might be missing a better way to do this, but as far as I can tell, there isn't currently a way to use a different mozconfig for nightly builds vs. opt builds. I added a mechanism to do this with the optional 'nightly_mozconfig' setting, which takes precedence over 'src_mozconfig' if is_nightly() is True. Similarly, I had to add 'nightly_objdir' in order to find mach_build_properties.json, since its location changes depending on whether or not we're doing a universal build.
Attachment #8591776 - Flags: review?(jlund)
Attached patch mac-mozconfigSplinter Review
Add a new mozconfig for osx64 non-universal opt builds. I just copied the 'debug' mozconfig in that directory and removed '--enable-debug' and '--enable-dmd'. Please check through and make sure there aren't other settings that need to be removed/added for opt builds.

Also, should we change the name? I left it as 'nightly', because opt builds generally re-use the nightly mozconfig but just have IS_NIGHTLY unset. However, in this case it really is only opt and not nightly.
Attachment #8591780 - Flags: review?(bhearsum)
Comment on attachment 8591776 [details] [diff] [review]
bug1152031-osxbuilds

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

I think this is the least invasive. unfortunetly, 'nightly' builds don't come with their own mh config. we could do something at the buildbot level where we pass an addtional config file if nightly and has values for the macosx case. I'm not sure that would be worth it though. This seems fine.
Attachment #8591776 - Flags: review?(jlund) → review+
Comment on attachment 8591780 [details] [diff] [review]
mac-mozconfig

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

::: browser/config/mozconfigs/macosx64/nightly
@@ +1,1 @@
> +. $topsrcdir/build/macosx/mozconfig.common

Our naming for these mozconfigs is so crazy :(. Someday we should probably separate CI and nightly mozconfigs, if only to stop using things called "nightly" for CI builds...

That's obviously not something to fix here though!
Attachment #8591780 - Flags: review?(bhearsum) → review+
Keywords: leave-open
There is a downside to this change: it makes it a PITA when you *do* want to do universal builds on try.
(In reply to Mike Hommey [:glandium] from comment #8)
> There is a downside to this change: it makes it a PITA when you *do* want to
> do universal builds on try.

Can't you just 'cp macosx-universal/nightly macosx64/nightly' and include that as part of the try push? I agree it's certainly not ideal, but it's not as much of a PITA as it is to actually test a nightly build.
You forget the part where the objdir where buildbot and/or mozharness run commands is obj-firefox/i386 in unified builds...
Ahh right, sorry. I guess you'd have to push to a user mozharness repo to use the universal config & obj-firefox/i386.
That sucks pretty bad. Can we figure out a way to make this a trychooser option or something before we do this? Otherwise people who break universal builds (which is more likely than PGO since the universal build stuff is fiddly) won't have an easy way to verify they've fixed it.
Given #c12, is the assumption in this bug that OSX universal builds break infrequently incorrect?

Regarding trychooser, I guess we'd need a separate platform for 'OSX universal opt' that is off everywhere by default -- is that possible?
Flags: needinfo?(catlee)
We've never tracked whether or not we specifically break postflight, as opposed to just breaking opt OS X, because we haven't had non-universal opt builds to tell the difference between "opt broke and debug didn't because it was opt bustage" and "opt broke and debug didn't because it was universal bustage." Of course, nobody in releng who was involved in this decision has any basis at all to have had an opinion, but no sheriff will be able to say either, because why one build broke isn't our mission, just that it did break. The assumption that they break infrequently is provably false since bug 1059460 is exactly "You break OS X universal builds when you remove a jarred file" and we do that around once a week, but as to how often we break clobbered universal builds like nightlies will be while not breaking non-universal, there is absolutely no way to know. (We can, however, be certain that this change will mean that building dep universal will no longer be supported, that if you want to build universal you will only be able to do so by clobbering.)
jlund, parts of mozharness are planned to go in-tree sometime in Q2, right? Would that help the case where we want to do OSX opt as non-universal by default, but allow someone to override that to a universal build on a try push? If so, maybe we can just back out the mozharness change for now until that's ready.
Flags: needinfo?(jlund)
From IRC discussion, we also need to consider what happens on the release branches. Aurora has nightly build coverage, but beta/release/esrXX don't. And if we intend to eventually promote CI builds to release builds, we're definitely going to need universal builds enabled on those branches.
Comment on attachment 8591776 [details] [diff] [review]
bug1152031-osxbuilds

Backing out for now: https://hg.mozilla.org/build/mozharness/rev/f443fb123c72

We'll need to sort out how to more easily test universal builds on try if non-universal is the default (does this go away if more of mozharness is in-tree? Or do we still need trychooser support?) And we'll need to figure out how to handle #c17 in mozharness.
Attachment #8591776 - Flags: checked-in+
(In reply to Michael Shal [:mshal] from comment #15)
> jlund, parts of mozharness are planned to go in-tree sometime in Q2, right?
> Would that help the case where we want to do OSX opt as non-universal by
> default, but allow someone to override that to a universal build on a try
> push? If so, maybe we can just back out the mozharness change for now until
> that's ready.

if you mean can we change the objdir and mozconfig for try pushes, absolutely. We can already thanks to mh pinning but it will be more transparent when mh is actually in tree (end of q2).
Flags: needinfo?(jlund)
Assignee: mshal → nobody
Clearing for now - we'll revisit this some other time.
Flags: needinfo?(catlee)
Universal builds are going away in Firefox 53.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.