Closed Bug 514305 Opened 12 years ago Closed 12 years ago

Support WinCE in release automation

Categories

(Release Engineering :: General, defect, P5)

ARM
Windows CE
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: nthomas, Unassigned)

References

Details

(Whiteboard: [wince])

Attachments

(5 files, 1 obsolete file)

The plan is to promote WinCE to a release platform for Firefox 3.6b1 so we need to investigate making that happen. In particular supporting updates from an interim WinCE-only release.
Blocks: 514307
So the initial requirements are:
* an en-US build producing zip, cab, and complete mar
* updates from previous releases
* update verify

L10n builds and signing are not required at this point.

For building, I've tested that ReleaseBuildFactory works OK. The files go into 
 $candidates-dir/wince-arm/en-US/, $candidates-dir/update/wince-arm/en-US/
which is fine given we don't need to sign.

Updates is the tricky bit. The easiest way forward is to use a separate patcher config for WinCE, because we'll have a WinCE-only release and because it saves on a huge <exceptions> block to handle the locales difference (similarly shipped-locales). The cost is an extra builder and doing two pushsnips, not so big I don't think.

Update verify we'll ask QA to do in the short term. We'll need devices or and emulators to test the updater in-situ.

So I'm leaning to a WinCE specific extension to release_master.py for now, and it can get integrated properly if it starts to move closer to the other platforms. It'll only have build and updates for now.
Oh, and AUS needs some tweaks. At the least, to know how to map a wince-arm platform to Bouncer and AUS equivalents.
Attached patch Add en-US build support (obsolete) — Splinter Review
Ben, there are several changes in here
* add a buildWinCE param to control doing a WinCE build, en-US only. Enabled for m-1.9.2 and m-c but not m-1.9.1. Later this will also add a WinCE updates step
* update the two release-firefox-mozilla-1.9.2.py for the post branch world, and add basic settings for WinCE-only 3.6a2 release (just planning to manually force a build after manual branch and tag of m-1.9.2)
* add a release mozconfig, compared to the nightly one it tweaks the update channel and enables official branding
Attachment #399995 - Flags: review?(bhearsum)
Attachment #399995 - Flags: review?(bhearsum) → review+
Comment on attachment 399995 [details] [diff] [review]
Add en-US build support

I know this release is pretty urgent, so I'll r+ this, but I think we can do this a little more cleanly. In my head this seems cleaner, what do you think Nick?:
* add wince to releasePlatforms
* create l10nPlatforms, leaving out wince
* control the schedulers and l10n builders based on l10nPlatforms

It might be better to rename releasePlatforms to enUSPlatforms, too.

Also, could we merge the wince-only patcher config with the main one if we dropped the 3.6a2 entry? Maybe this is something we could do after a couple of simultaneous ones, or after the final version. I think that would be better for maintainability.
The alternative approach Ben suggested. Logically is this is the same but hopefully more readable. Obviously it assumes that enUSPlatforms is a superset of l10nPlatforms.

Also updates 1.9.2 release config to 3.6a2 & m-c config to 3.7a1. It creates a wince_update_verify that will burn until we figure out a solution there, but looping over enUSPlatforms seems more honest than using l10nPlatforms. Also fixes some tabs in the FtpPoller change source in release_master.py. The changes in repack scheduler and factory are strictly indents only, but even diff -w doesn't figure that out.
Attachment #400660 - Flags: review?(bhearsum)
CC'ing Gozer and KaiRo as the changes here impact automation configs for their apps. (PS: Having a ':kairo' to match on would be awesome!)
Comment on attachment 400660 [details] [diff] [review]
Add en-US build support, take 2

Looks good to me. I guess we'll have to removing the hardcoding of platforms in patcher-config-bump.pl pretty soon, too - eh?
Attachment #400660 - Flags: review?(bhearsum) → review+
Those changes also sound nice in the way that they should make it easier to roll en-US-only x86_64 builds for releases to put up as "contributed" builds ;-)
Attachment #399995 - Attachment is obsolete: true
Comment on attachment 400660 [details] [diff] [review]
Add en-US build support, take 2

Belay that last comment, I used rebase to handle an upstream change, so the revision changed to
http://hg.mozilla.org/build/buildbot-configs/rev/366c3f955fbc
Produces snippets like this for a fake 3.6b1 release:

==> aus2.test/Firefox/3.6a2/WINCE_arm-msvc/20090915194311/en-US/releasetest/partial.txt <==
version=1
type=partial
url=http://download.mozilla.org/?product=firefox-3.6b1-partial-3.6a2&os=wince&lang=en-US
hashFunction=SHA512
hashValue=d942245a52e8c1199e150c37c4599a....
size=634701
build=20090916666666
appv=3.6 Beta 1
extv=3.6b1
detailsUrl=http://www.mozilla.com/en-US/firefox/3.6b1/releasenotes/
Comment on attachment 401161 [details] [diff] [review]
patcher support (release updates)

Coop, this adds support for WinCE Firefox builds. In bouncer we use 'wince' for the OS, the build system has 'wince-arm' as the platform (so that's what we get in the directory layout in the candidates dir), and the platform identifier in the app requests is WINCE_arm-msvc.

This would be used to create UPDATE_PACKAGING_R10.
Attachment #401161 - Flags: review?(ccooper)
Attachment #401161 - Flags: review?(ccooper) → review+
Comment on attachment 401161 [details] [diff] [review]
patcher support (release updates)

Checking in MozAUSLib.pm;
/cvsroot/mozilla/tools/patcher/MozAUSLib.pm,v  <--  MozAUSLib.pm
new revision: 1.12; previous revision: 1.11
done
Attachment #401161 - Flags: checked-in+
UPDATE_PACKAGING_R10 created using the procedure in bug 420947 comment #17.

The changes between R9 and R10 are
*  tags in client.mk (to pull the right code)
*! this bug's change to MozAUSLib.pm
*  bug 496491, Bootstrap change, not part of the patcher "build"
*  bootstrap config changes, not part of the patcher "build"
*! fix to tools/update-packaging/make_incremental_updates.py from bug 507405
*  added tools/update-packaging/test_make_incremental_updates.py in bug 444050, not part of the patcher "build"

The items marked *! are the only changes that bear on release updates.
Adds cab to the whitelist for gpg sigs and hashing.
Attachment #406160 - Flags: review?(bhearsum)
Attachment #406160 - Flags: review?(bhearsum) → review+
Comment on attachment 406160 [details] [diff] [review]
Create gpg sigs and include in *SUMS files

Landed:
Checking in checksum-files;
/mofo/release/stage/checksum-files,v  <--  checksum-files
new revision: 1.5; previous revision: 1.4
done

cvs commit: Examining .
Checking in sign-files;
/mofo/release/signing/tools/sign-files,v  <--  sign-files
new revision: 1.5; previous revision: 1.4
done
Attachment #406160 - Flags: checked-in+
Every time we do a 3.6 update generation run it appears to fail because it can't bump a WinCE update verify config ("failed bump_verify_configs_4"). Since we can't do verify on WinCE lets stop trying to bump, by removing the line from config from verifyConfigs. Also removes the useless builder by also keying their creation off verifyConfigs instead of enUSPlatforms.
Attachment #415802 - Flags: review?(bhearsum)
Comment on attachment 415802 [details] [diff] [review]
Fix false bustage in update generation

Slightly aside, but it might make more sense to call it verifyPlatforms or updateVerifyPlatforms now that we're keying logic off of it.

What do you think? r=me either way.
Attachment #415802 - Flags: review?(bhearsum) → review+
Comment on attachment 415802 [details] [diff] [review]
Fix false bustage in update generation

Yeah, that's be a good plan. Lets follow up though 'cos it'll require some co-ordination with T'Bird/SeaMonkey/Sunbird.

Also updated verifyConfigs in 2x release-firefox-mozilla-central.py on checkin:
http://hg.mozilla.org/build/buildbot-configs/rev/3bdc5139e4b5
Attachment #415802 - Flags: checked-in+
Depends on: 531275
Given the recent "deprioritizing" of WinCE, and stopping of WinCE builds in bug
543067, should this be closed as WONTFIX? If the WinCE situation changes, we can always reopen.

Of course, if there is valid work going on here unrelated to WinCE, then never mind, and carry on.
The remaining work here is to automate producing updates for WinCE. If we're not going to be producing nightly and release builds for WinCE then I agree we should close this.
(In reply to comment #22)
> The remaining work here is to automate producing updates for WinCE. If we're
> not going to be producing nightly and release builds for WinCE then I agree we
> should close this.

Nightly and release builds for WinCE stopped.
Assignee: nrthomas → nobody
Priority: -- → P5
Status: ASSIGNED → NEW
In case we decide to resume any work we will have to undo the work of bug 543067.

Reopen or file a new one when WinCE becomes an active project.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Whiteboard: [wince]
I'm being nit picky today -- this is a valid bug (ergo not INVALID) but definitely WONTFIX at this time.
Resolution: INVALID → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.