Closed Bug 1242374 Opened 6 years ago Closed 6 years ago
With Firefox 44
.0 Build 3 we ship firefox-44 .0 .sdk .zip packages for en-US win32/win64 builds
Today I have seen a lot of test failures for our Firefox UI tests and the latest Firefox 44.0 build 3 on Windows - but only for en-US! Some deeper investigation has shown that we somehow upload some strange SDK packages for those builds to the FTP server. http://archive.mozilla.org/pub/firefox/candidates/44.0-candidates/build3/win32/en-US/ > File firefox-44.0.sdk.zip 79M 24-Jan-2016 02:29 > File firefox-44.0.sdk.zip.asc 836 24-Jan-2016 02:29 Sadly those files are referenced in the Mozilla Pulse build notifications: "buildurl": "http://archive.mozilla.org/pub/firefox/candidates/44.0-candidates/build3/win32/en-US/firefox-44.0.sdk.zip" That means something in the Releng system behaves incorrectly or its something new which needs tweaking. Interesting is that no-one seems to know what this file is for. So do we really want to upload that?
I just noticed that the patch on bug 1233005 landed last week. So with that we seem to incorrectly set the buildurl. But what I still wonder is why we only upload it for win32/win64? Should this file go into another folder?
Also I do not see any SDK build under candidate builds even before Firefox 44.0.
It's expected that we're building the SDK as part of Firefox now. We used to build it as part of XULRunner, but that died. This transition was done in bug 1233005. What used to be the "buildurl" here? The firefox zip?
Looks like, yes. Here the buildurl for 44.0 build 1: "buildurl": "http://archive.mozilla.org/pub/firefox/candidates/44.0-candidates/build1/win32/en-US/firefox-44.0.zip"
Whereby an installer_url might also be great to have so that we can actually test the installer again, which we cannot do with the zip file having present only.
Per our IRC discussion, this sets a dummy sdkUrl variable so we don't hit the 'else' case for packageUrl. In staging here's the before: packageUrl: 'http://archive.mozilla.org/pub/firefox/candidates/41.0-candidates/build2/linux-i686/en-US/firefox-41.0.sdk.tar.bz2' and after: packageUrl: 'http://archive.mozilla.org/pub/firefox/candidates/41.0-candidates/build2/linux-i686/en-US/firefox-41.0.tar.bz2'
Assignee: nobody → mshal
Attachment #8711879 - Flags: review?(bhearsum)
Comment on attachment 8711879 [details] [diff] [review] sdkurl.patch Review of attachment 8711879 [details] [diff] [review]: ----------------------------------------------------------------- Looks plausible to me...thanks Mike!
Attachment #8711879 - Flags: review?(bhearsum) → review+
Summary: With Firefox 44.0 Build 3 we ship some strange firefox-44.0.sdk.zip packages for en-US win32/win64 builds → With Firefox 44.0 Build 3 we ship firefox-44.0.sdk.zip packages for en-US win32/win64 builds
Comment on attachment 8711879 [details] [diff] [review] sdkurl.patch https://hg.mozilla.org/build/buildbotcustom/rev/34f988f27f10
Attachment #8711879 - Flags: checked-in+
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
Oops, sorry about that accidental closure.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
And in production after after a reconfig.
I assume this bug can be marked as fixed now? Today's beta build didn't show any problem and I think the patch here relates to all release builds.
Are these builds (both SDK and .exe) available on archive.mozilla.org?
Yes, see my comment 0. Not sure why those only appear under Windows builds.
I believe this is fixed.
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.