Closed Bug 937865 Opened 11 years ago Closed 7 years ago

Simplify download buttons using the firefox-latest product in bouncer

Categories

(www.mozilla.org :: Bedrock, defect)

Product:
www.mozilla.org
Component:
Bedrock
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: pmac, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [kb=1180351] )

Attachments

(1 file)

Link to GitHub pull-request: https://github.com/mozilla/bedrock/pull/5225
44 bytes, text/x-github-pull-request
Details | Review
Now that bug 863381 is fixed, it appears that the "firefox-latest" product works in bouncer for all supported platforms. This means that we no longer need product-details to get the latest firefox release version for most download buttons. We'll mostly now only need it for up-to-date checking and the "all" pages.
Whiteboard: [kb=1180351]
FYI, we haven't got firefox-beta-latest set up yet (bug 937839) but it's coming. Aurora will probably stay as is.
Depends on: 937839
Bug 950119 reported a 404 issue on the Aurora link. It would be nice to have firefox-aurora-latest too :)
Flags: needinfo?(nthomas)
Bug 731299 has some context on why this isn't just a 2 minute job in configuring bouncer.
Flags: needinfo?(nthomas)
Blocks: download-buttons
pmac, is this bug still valid?
Flags: needinfo?(pmac)
I think it might be. There are more "*-latest" products in bouncer now but I'm not sure they're all there, and I think we may still need to do some work on the buttons to support them all. We should take stock.
Flags: needinfo?(pmac)
AFAIK some are missing and inconsistent. The -SSL suffix could be dropped as secure downloads have been defaulted for some time.
Exactly. We should try to work with release management on cleaning these up and making them consistent.
If I understand correctly, this is proposing changing the link targets on pages like https://www.mozilla.org/en-US/firefox/all/ from: https://download.mozilla.org/?product=firefox-40.0.3-SSL&os=linux64&lang=en-US ...to: https://download.mozilla.org/?product=firefox-latest&os=linux64&lang=en-US Is that correct? If so, this would actually help solve a discoverability problem with the "latest" links, which is causing people to scrap HTML to generate the binary URLs, since they don't know about the aliases. eg: https://github.com/travis-ci/travis-build/blob/c858502ddce77cc90f88c8871f1fff3982d1f8a6/lib/travis/build/addons/firefox.rb#L61
s/scrap/scrape/
Depends on: 1256958
Depends on: 1257214
We see Windows XP/Vista users confused by the versioned download links because of this: https://support.mozilla.org/en-US/kb/get-latest-version-thunderbird-windows-xp-vista So that product=firefox-latest would be preferred, but it's currently broken as reported in Bug 1257214.
See Also: → 1301433
Hey there, follow-up from https://bugzilla.mozilla.org/show_bug.cgi?id=1305139#c53: 1) Just discovered the download-installer.cdn.mozilla.net, why isn’t it used for Nightly links (here for instance: https://www.mozilla.org/en-US/firefox/nightly/all/) ? 2) This link https://download.mozilla.org/?product=firefox-latest&os=linux64&lang=en-US mentioned above redirects to https://download.cdn.mozilla.net/pub/firefox/releases/51.0.1/linux-x86_64/en-US/firefox-51.0.1.tar.bz2 which produces HSTS error either because of HPKP or CN ( a248.e.akamai.net, *.akamaized.net, *.akamaihd-staging.net, *.akamaihd.net, *.akamaized-staging.net ). Regarding 2, I was in fact trying to find a way to get the latest fr nightly for linux x86_64, after discovering that link: https://download.mozilla.org/?product=firefox-aurora-latest-ssl&os=linux64&lang=en-US I’ve then been playing around to try to download it. The -ssl part in it make me think you’re aware of this certificate issue (since this links, pointing toward download-installer.~), but https://download.mozilla.org/?product=firefox-latest-ssl&os=linux64&lang=en-US doesn’t work, so… Also, https://download.mozilla.org/?product=firefox-aurora-latest-ssl&os=linux64&lang=fr returns the en-US version. As does: https://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=linux64&lang=fr Finally, just a more personal comment: download-installer.~ is a very ugly name, I hope this is temporary and was because of the HSTS error on download.~ but that it will be reverted once everything will be fixed. ;)
Let's get this moving again. As far as I can tell, the current status is that we can and are using the *-latest-ssl bouncer product names for devedition and nightly, but no such aliases exist for beta or release. There is firefox-latest and firefox-beta-latest, but those redirect to insecure URLs and I believe are meant for use by the stub installer which independently verifies the downloads. So all we need to proceed is firefox-latest-ssl and firefox-beta-latest-ssl for all platforms and locales. Any idea how possible this might be :nthomas?
Flags: needinfo?(nthomas)
Here's the current state of the aliases in bouncer: Alias Related product firefox-devedition-latest Devedition-56.0b1 firefox-devedition-latest-ssl Devedition-56.0b1-SSL firefox-devedition-stub Devedition-56.0b1-stub firefox-beta-latest Firefox-56.0b1 firefox-beta-stub Firefox-56.0b1-stub firefox-latest Firefox-55.0.1 Firefox-stub Firefox-55.0.1-stub firefox-esr-latest Firefox-52.3.0esr Plus some odds and ends: firefox-sha1 Firefox-52.3.0esr-sha1 firefox-latest-euballot Firefox-35.0-EUBallot devedition-latest Devedition-54.0b14 # these three can probably be removed devedition-latest-ssl Devedition-54.0b14-SSL devedition-stub Devedition-54.0b14-stub So asking for firefox-beta-latest-ssl and firefox-latest-ssl makes sense and is to problem to add. What about adding a firefox-esr-latest-ssl ? Or firefox-sha1-ssl ? The latter is related to XP/Vista and SHA1 signed builds. Once we have a consensus we can create a bug in the RelEng component and we can adjust the release automation config.
Flags: needinfo?(nthomas)
See Also: → 1387622
That sounds great. We should file that bug for: * firefox-beta-latest-ssl * firefox-latest-ssl * firefox-esr-latest-ssl I see firefox-sha1 already redirects to an HTTPS download, but for consistency it would be nice to have firefox-sha1-ssl as well. As far as www.m.o is concerned we can indeed remove the devedition-* ones, the site is using the firefox-devedition-* ones. I'll file said bug shortly as a blocker to this one. Thanks!
Depends on: 1387622
See Also: 1387622 →
pmac, will we use product-details for anything related to download boxes/all pages/etc after this ? Wondering from the point-of-view of informing release management about it, in particular if some pages will still require a bedrock deploy to update.
We no longer require a deployment to update. The data is updated in the background, but only every hour or so. We do still rely on product-details for the build info which let's us generate the /all pages with an accurate list of all available platforms and languages. We also still somewhat rely on the latest version info to power some messaging on the site that informs users if they're too far out-of-date, or to change some things around if they're on pre-release. But it's true that most download links moving to use the *-latest bouncer products does mean that the buttons will be more simple and no longer rely on product-details.
Thanks for the background info. Bug 1387622 is all done so you can go ahead with bedrock changes.
(In reply to Paul [:pmac] McLanahan ⏰ET needinfo? me from comment #14) > I see firefox-sha1 already redirects to an HTTPS download, but for > consistency it would be nice to have firefox-sha1-ssl as well. FTR we backed this bit out, because the internals of bouncer depend on the firefox-sha1 alias.
Commit pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/98d8bd330648a25731cbc2920b052f4fcf983830 Fix bug 937865: Use new firefox-*-latest-ssl bouncer products (#5225) Only esr_next should use the version number now.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
So I have a question - if the aforementioned PR landed in bedrock, when should we expect the mozilla.org website to point to the new entries, instead of the versioned ones? I don't know very well the mechanics behind that. Thanks! [1]: view-source:https://www.mozilla.org/en-US/firefox/new/?scene=2
The basic answer is "the next time we deploy to production", which should be sometime today. We're not on a schedule per se, but we do usually deploy daily.
These changes are now in production.
Status: RESOLVED → VERIFIED
(In reply to Paul [:pmac] McLanahan ⏰ET needinfo? me from comment #23) > These changes are now in production. This is awesome, thank you!
mbrandt, does your bouncer test suite need any updates for the changes here ?
Flags: needinfo?(mbrandt)
nthomas, thanks for the ping. No, our bouncer test suites won't be effected by this change. r+
Flags: needinfo?(mbrandt)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: