Closed Bug 836041 Opened 13 years ago Closed 13 years ago

Can't provide alternate mozconfigs for comm-esr17 when building esr versus mainstream

Categories

(Release Engineering :: Release Requests, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: standard8, Unassigned)

References

Details

Attachments

(2 files, 2 obsolete files)

Issue: For TB 17 mainstream & TB 17 esr, we want to build both off of comm-esr17 with different mozconfigs for esr versus release. However, this is currently not possible for l10n-mozconfigs as the location is hard-coded based on source repository: http://hg.mozilla.org/build/tools/annotate/945eec76c4d6/scripts/l10n/create-release-repacks.py#l186 mozconfig = path.join("buildbot-configs", "mozilla2", options.platform, sourceRepoInfo['name'], "release", "l10n-mozconfig") This means we can't set up different options (e.g. channel name, add add export MOZ_ESR=1).
I think this is the main thing blocking building TB 17 ESR and mainstream from the comm-esr17 repos (bug 815302), but I do not have time to work on it. Options I see are: 1) Change the current scripts to allow a different directory (or mozconfig name) e.g. mozconfig = path.join("buildbot-configs", "mozilla2", options.platform, sourceRepoInfo['name'], config["l10n_mozconfig_dir"], "l10n-mozconfig") 2) Move the mozconfigs to be in-tree as per bug 758149
Since the only difference between esr and release mozconfigs is the export MOZ_ESR=1, we could try a workaround and export that MOZ_ESR=1 via the buildbot-configs. eg. http://hg.mozilla.org/build/buildbot-configs/file/6fef12fe7bcd/mozilla/thunderbird_config.py#l948 As standard8 points out, it would also have to work for l10n.
Attached patch set MOZ_ESR only for esr (obsolete) — — Splinter Review
(In reply to John Hopkins (:jhopkins) from comment #2) > Since the only difference between esr and release mozconfigs is the export > MOZ_ESR=1, we could try a workaround and export that MOZ_ESR=1 via the > buildbot-configs. > > eg. > http://hg.mozilla.org/build/buildbot-configs/file/6fef12fe7bcd/mozilla/ > thunderbird_config.py#l948 > > As standard8 points out, it would also have to work for l10n. 11:29 < bhearsum> is there any harm that could be done by having MOZ_ESR=1 set for all of the jobs on the esr branch (that is, dep, nightly en-US/l10n, etc.) (cc Standard8) 11:30 < Standard8> hmm 11:31 < Standard8> bhearsum: so we don't really want it set for dep/nightly builds ...so we can't do what's suggested in comment #2. This patch should solve the problem though.
Comment on attachment 709094 [details] [diff] [review] set MOZ_ESR only for esr I think we need to add if [ "${MOZ_UPDATE_CHANNEL}" = "esr" ]; then and fi to the whitelist now because of this....
(In reply to Ben Hearsum [:bhearsum] from comment #4) > Comment on attachment 709094 [details] [diff] [review] > set MOZ_ESR only for esr > > I think we need to add if [ "${MOZ_UPDATE_CHANNEL}" = "esr" ]; then and fi > to the whitelist now because of this.... Just remembered, if we're doing this, we also need to replace the --enable-update-channel from "esr" to "${MOZ_UPDATE_CHANNEL}" as otherwise mainstream will get built wrong.
Sets MOZ_ESR only for ESR, and changes the update channel to be based on ${MOZ_UPDATE_CHANNEL}.
Attachment #709094 - Attachment is obsolete: true
Attachment #710866 - Flags: review?(jhopkins)
Attachment #710866 - Flags: review?(jhopkins) → review+
Attachment #710875 - Flags: review?(mbanner)
Attachment #710875 - Attachment is obsolete: true
Attachment #710875 - Flags: review?(mbanner)
Attachment #710890 - Flags: review?(mbanner)
Comment on attachment 710890 [details] [diff] [review] [tools] add if/fi to comm-esr17 exceptions list (not present in nightly mozconfig) Looks good
Attachment #710890 - Flags: review?(mbanner) → review+
Comment on attachment 710890 [details] [diff] [review] [tools] add if/fi to comm-esr17 exceptions list (not present in nightly mozconfig) Landed in http://hg.mozilla.org/build/tools/rev/7518cfdc0c6a
Attachment #710890 - Flags: checked-in+
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: