Bug 1332726 is an unusually long-lived funnelcake study where we will need to regenerate installers for all 52.0.x and possibly 53.0* versions. This bug is to look into automating that process so that releaseduty is not burdened by lots of manual work.
Rail, could you please let me know your thoughts on this proposal. The tl;dr on bug 1332726 is that it's 4 funnelcakes, a single locale for each on win32. The funnelcake config itself is static, we just need to keep rebuilding and publishing this funnelcake for 6 or more weeks - triggered by a Firefox on the release channel coming along (aka alwats provide the most secure version available from the initial download). No stub installers to worry about. The current process is described in attachment 8844318 [details]. 1, Repack generation Piggy back on the EME-free job by adding funnelcake into the manifest at https://github.com/mozilla-partners/mozilla-EME-free-manifest/blob/master/default.xml. The 'firefox mozilla-release win32 EME-free repacks' task should spit out the funnelcakes into the candidates directory, with run time only slightly longer than now. 2, Push to releases directory Currently we upload into partner-repacks/funnelcake101/ etc in the candidates directory, but push to mirrors excludes partner-repacks. So I'm thinking we change the funnelcake config to push into win32-funnelcake101/ etc in the candidates dir instead, similar to what EME-free does, and we get the push for free. Not sure if there is anyone who needs to signoff on the change of locations (eg from releases/52.0-funnelcake101/win32/ to releases/52.0/win32-funnelcake101), doesn't seem like a big deal to me. 3, Update bouncer aliases www.mozilla.org is using urls like https://download.mozilla.org/?product=firefox-stub-f101&os=win&lang=en-US. This is currently a proper product with a single location, but considering changing that to an alias which gets updated in the 'bouncer aliases' task. So adjust releases/bouncer_firefox_release.py to setup products Firefox-%(version)s-f101 etc in the bouncer submission task, and define alias 'firefox-stub-f101' on that. 4, Verify bouncer is working Probably easiest to modify our nagios check - https://hg.mozilla.org/build/nagios-tools/file/tip/nagios_tools/scripts/check_bouncer.py#l64 - to include the four funnelcakes. This would all last as long as this funnelcake then get backed out. If this plan sounds OK can I test it on jamun ?
The plan sounds good to me! A nit. EME-free is used on beta, so we'll have those there to. Maybe not a big deal.
Maybe a separate repack job for funnelcake101-104 then. There are a few new funnelcakes in the repo too, which may or may not need building each time.
101-104 are on hold.
Do we still track this or can we close it?
The specific case of funnelcake 103 & 104 has decayed away but there are recent examples like bug 1450463, and possibly bug 1452807. We seem to be using funnelcake as a way to have a custom firstrun page, which are live longer than the previous 'test if this change helps retention' studies. IMO we shouldn't serve older versions of Firefox due to known sec issues, crashes, regressions etc. So it would be helpful for the automation to handle this rather than it fall on releaseduty. To update the original description with current status * we repack funnelcake for all release channel releases (and the 2nd half of a beta cycle) via the main partner repacking tasks * they get beetmoved into firefox/candidates/<version>-candidates/build<buildnumber>/partner-repacks/funnelcake/ on archive.m.o * recently we've not been copying them anywhere before 'shipping', so the bouncer links point into the candidates directory * so we just have to update the bouncer locations when a new release comes along This means we have less work to do, but need to take care with getting buildN right, and updating the version correctly, in each location.
Summary: Automate funnelcake101-104 builds for Firefox 52.0 and 53.0 → Automate long-lived funnelcakes
You need to log in before you can comment on or make changes to this bug.