Closed Bug 644202 Opened 9 years ago Closed 9 years ago

prep automation to merge mobile in

Categories

(Release Engineering :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aki, Assigned: aki)

References

Details

Attachments

(5 files, 4 obsolete files)

There's a *lot* of assuming that a mobile build will have two repos.
We need to make sure that when we merge mobile-browser into mozilla-central, nothing breaks.
Blocks: 643007
We're going to hit a tbpl issue: we rely on the branch being mozilla-central-mobile-browser to differentiate mobile builds from desktop builds.

Android and Maemo are one thing; win32/osx/linux fennec desktop builds may cause further confusion.

How should we deal with this?  One potential solution is don't split them in tbpl anymore; I'm leaning towards this one.  Another is to pretend mobile-browser still exists, for tbpl purposes.
For Try, I'm thinking we're going to

a) not have a mobile repo
b) if you want to build a revision or release branch before the mobile-browser merge and you want mobile builds, you need to add mobile-repo and mobile-rev files.
Attached patch mozharness diffSplinter Review
For deb repos, I probably want a followup bug to be able to look at a URL for the locales list, rather than have to check out all of m-c for the one file.
Attached patch configs diffSplinter Review
This massive one-liner is all that's required in buildbot-configs so far.  debsign/ is handled by mozharness. mozilla2/ and mozilla2-staging/ cover Fennec 1.x nightlies/incrementals/releases and 4.x releases and can be EOLed once Fennec 5.0 is out the door.  Most of the heavy lifting/ugliness is in the next patch (buildbotcustom).
Comment on attachment 521397 [details] [diff] [review]
configs diff

Oh -- if we land this as is, it expects that all project branches also have mobile-browser merged in. That probably means there's going to be some tree burning, or we need to specify mobile_repo_path for each project branch and remove it whenever they merge from m-c.
This adjusts generateMobileBranchObjects() and adjusts MobileBuildFactory and its children to make mobileRepoPath optional.

TODO: I need to revisit MobileBuildFactory's enable_try hg repo cloning steps. This will probably check for a mobile/ directory; if that doesn't exist, look for the mobile-repo file; if that doesn't exist, error out.

I also tore out the unused MobileNightlyRepackFactory and its children; that's currently run by ScriptFactory. (Speaking of, nightly-mobile-repacks.py and nightly_mobile_repacks.sh probably need patching as well.)
Attached patch [untested] tools diff (obsolete) — Splinter Review
I *think* this'll work. As with the buildbot-configs and buildbotcustom repos, we can live with some additional ugliness until Fennec 5 ships, and all moz+mob repo configurations are EOLed.
This patch makes the try logic the default for all builds that don't need a mobileRepoPath.  This patch assumes that try will stop supporting separate locales on day one of the merge, but could be modified by adding an elif condition.

The mobile: link is still printed, with the same revision as mozilla-central for legacy tools that may require both revisions for scraping.

For builds that still have mobileRepoPath, nothing is changed
Attachment #521529 - Flags: feedback?(aki)
Comment on attachment 521529 [details] [diff] [review]
rip out the mobile directory when not needed

Hm, maybe, if we change the mode='clobber' to 'update' if not self.enable_try.

Allowing for the mobile_repo/mobile_rev files are actually needed until 4.0 is EOLed, however, so this patch needs work.
Attachment #521529 - Flags: feedback?(aki) → feedback-
(In reply to comment #9)
> Comment on attachment 521529 [details] [diff] [review]
> rip out the mobile directory when not needed
> 
> Hm, maybe, if we change the mode='clobber' to 'update' if not self.enable_try.

sure

> Allowing for the mobile_repo/mobile_rev files are actually needed until 4.0 is
> EOLed, however, so this patch needs work.

We don't support 1.9.2 on try right now aiui, I don't see why we would support mobile 4.0 on try.  Anyway,  the mobile_repo/mobile_rev files were try only, so it really shouldn't make any difference.  If someone really does need to push to try with 4.0, they could use the mobile_rev and mobile_repo file on a pre-merge tree by doing something like:

cd mozilla-central
test -d mobile || hg clone http://hg.mozilla.org/`cat mobile_repo` mobile
hg up -R mobile -r `cat mobile_rev`
mv mobile/.hg mobile/.hg-old
hg add mobile/*
hg commit -m "Adding mobile for pushing to try"
hg push -f ssh://hg.mozilla.org/try
hg rollback
hg forget mobile/*
mv mobile/.hg-old mobile/.hg
* standard builds look good
* l10n scripts need fixing
* still need to revisit try
So I think the repack failed because it was looking in mobile/locales/l10n.ini, which is no longer at the top of an external repo anymore.

I'm taking a stab at a mozilla-central/mobile/locales/l10n.ini, but I'm not sure if this will work.
Attachment #521735 - Flags: feedback?(l10n)
The l10n.ini change isn't required for this to work, but will probably be needed for the l10n dashboard.
Attachment #521411 - Attachment is obsolete: true
I added a check to see if there's a mobile dir, and if not, then require the mobile-repo rigmarole.  This further complicates and uglifies the mobile checkout code, but we can tear all of this out once Fennec 5 ships and we EOL previous versions.

I have tested the non-try portions of this patch; I need to test the try portion.

This also has the fix from bug 629498.
Attachment #521403 - Attachment is obsolete: true
Attachment #521529 - Attachment is obsolete: true
Comment on attachment 521735 [details]
is this a good mobile/locales/l10n.ini ?

almost, drop the 'tld = mobile' line? That's also part of the one-off mobile logic.
Attachment #521735 - Flags: feedback?(l10n) → feedback+
Comment on attachment 521748 [details] [diff] [review]
tools v2: working l10n repacks

My try testing went well. I'll flag these for review, and write up something about the merge logistics.
Attachment #521748 - Flags: review?(bhearsum)
Attachment #521397 - Attachment description: [untested] configs diff → configs diff
Attachment #521397 - Flags: review?(catlee)
Attachment #522045 - Attachment description: [untested] buildbotcustom patch with try → buildbotcustom patch with try
Attachment #522045 - Flags: review?(catlee)
Attachment #521391 - Flags: review?(coop)
Attachment #521391 - Attachment description: [untested] mozharness diff → mozharness diff
Attachment #521391 - Flags: review?(coop) → review+
Comment on attachment 521748 [details] [diff] [review]
tools v2: working l10n repacks

Just to make sure I understand fully: mobileBranch is kept, but made optional, in order to allow this to work for integrated and non-integrated style repacks?
Attachment #521397 - Flags: review?(catlee) → review+
Attachment #522045 - Flags: review?(catlee) → review+
(In reply to comment #17)
> Comment on attachment 521748 [details] [diff] [review]
> tools v2: working l10n repacks
> 
> Just to make sure I understand fully: mobileBranch is kept, but made optional,
> in order to allow this to work for integrated and non-integrated style repacks?

Yes.  4.x builds off mozilla-2.1/mobile-2.0 will need a mobileBranch; these will be EOLed once Fennec 5.0 ships.
Attachment #521748 - Flags: review?(bhearsum) → review+
(In reply to comment #1)
> How should we deal with this?  One potential solution is don't split them in
> tbpl anymore; I'm leaning towards this one.  Another is to pretend
> mobile-browser still exists, for tbpl purposes.

I don't have an opinion on this yet, I never use the Mobile tbpl. At the moment, failing mobile builds don't affect the Firefox tree state and don't keep people from checking in on mozilla-central, I think. Should they?

To which Tinderbox will mobile builds report?
(In reply to comment #19)
> (In reply to comment #1)
> > How should we deal with this?  One potential solution is don't split them in
> > tbpl anymore; I'm leaning towards this one.  Another is to pretend
> > mobile-browser still exists, for tbpl purposes.
> 
> I don't have an opinion on this yet, I never use the Mobile tbpl. At the
> moment, failing mobile builds don't affect the Firefox tree state and don't
> keep people from checking in on mozilla-central, I think. Should they?

This is a larger discussion that should probably happen, but I'm going to step out on a limb and say yes, broken mobile builds should stop checkins on m-c.

> To which Tinderbox will mobile builds report?

Mobile currently, but we can change that as well.
We probably need followup bugs, which will probably include l10n.ini updating.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Attachment #521735 - Attachment is obsolete: true
Attachment #524315 - Flags: review?(l10n)
Comment on attachment 524315 [details] [diff] [review]
fix l10n dashboard

r=me
Attachment #524315 - Flags: review?(l10n) → review+
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.