Closed Bug 1547710 Opened 1 year ago Closed 1 year ago

Add a FENNEC_NIGHTLY define for Fennec Nightly builds

Categories

(Firefox Build System :: General, task)

task
Not set

Tracking

(firefox68 fixed)

RESOLVED FIXED
mozilla68
Tracking Status
firefox68 --- fixed

People

(Reporter: RyanVM, Assigned: RyanVM)

References

Details

Attachments

(1 file)

As part of the migration of Fennec to ESR68, we need to create a new define for Nightly builds which isn't tied to the version number like NIGHTLY_BUILD is. This will allow for experimental code to land without being exposed to a wide audience off the bat.

Do we actually need this? I mean, we could have a nightly-like version in mobile/android/config/version.txt instead, and that should still define the right things.

How would that work when we're shipping multiple channels from the same tree?

Well, FENNEC_NIGHTLY doesn't help with that either, as it wouldn't enable NIGHTLY_BUILD. version.txt wouldn't actually work either, because NIGHTLY_BUILD depends on config/milestone.txt rather than $APP/config/version.txt.

How about something like:

diff --git a/build/moz.configure/init.configure b/build/moz.configure/init.configure
index f066b19f280ab..311333addd83d 100644
--- a/build/moz.configure/init.configure
+++ b/build/moz.configure/init.configure
@@ -1123,26 +1123,29 @@ def mozilla_official(official):
         return True
 
 
 set_config('MOZILLA_OFFICIAL', mozilla_official)
 set_define('MOZILLA_OFFICIAL', mozilla_official)
 add_old_configure_assignment('MOZILLA_OFFICIAL', mozilla_official)
 
 
+option(env='MOZ_MILESTONE', nargs=1, help='Milestone')
+
+
 # set RELEASE_OR_BETA and NIGHTLY_BUILD variables depending on the cycle we're in
 # The logic works like this:
 # - if we have "a1" in GRE_MILESTONE, we're building Nightly (define NIGHTLY_BUILD)
 # - otherwise, if we have "a" in GRE_MILESTONE, we're building Nightly or Aurora
 # - otherwise, we're building Release/Beta (define RELEASE_OR_BETA)
-@depends(check_build_environment, build_project, '--help')
+@depends(check_build_environment, build_project, 'MOZ_MILESTONE', '--help')
 @imports(_from='__builtin__', _import='open')
 @imports('os')
 @imports('re')
-def milestone(build_env, build_project, _):
+def milestone(build_env, build_project, moz_milestone, _):
     versions = []
     paths = ['config/milestone.txt']
     if build_project == 'js':
         paths = paths * 3
     else:
         paths += [
             'browser/config/version.txt',
             'browser/config/version_display.txt',
@@ -1157,16 +1160,19 @@ def milestone(build_env, build_project, _):
         with open(os.path.join(build_env.topsrcdir, p), 'r') as fh:
             content = fh.read().splitlines()
             if not content:
                 die('Could not find a version number in {}'.format(p))
             versions.append(content[-1])
 
     milestone, firefox_version, firefox_version_display = versions[:3]
 
+    if moz_milestone:
+        milestone = moz_milestone[0]
+
     # version.txt content from the project directory if there is one, otherwise
     # the firefox version.
     app_version = versions[3] if len(versions) > 3 else firefox_version
     # version_display.txt content from the project directory if there is one,
     # otherwise version.txt content from the project directory, otherwise the
     # firefox version for display.
     app_version_display = versions[-1] if len(versions) > 3 else firefox_version_display
 

In this case, we don't want NIGHTLY_BUILD to be set once 68 leaves mozilla-central since that'll leave experimental Gecko features enabled which will never ship on Fennec. The idea behind adding a new define for this is that it allows us to opt features into remaining enabled on Nightly builds without going all-in.

Pushed by rvandermeulen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/26788e97ef90
Add FENNEC_NIGHTLY define to Fennec nightly builds. r=mshal
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Blocks: 1548617
Blocks: 1606937
You need to log in before you can comment on or make changes to this bug.