Closed Bug 1249993 Opened 9 years ago Closed 9 years ago

fennec-47.0a1.multi.android-arm_info.txt lacks revision

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: peterbe, Assigned: oremj)

References

Details

Socorro's ftpscraper relies on getting the build ID AND the revision from these *_info.txt files. Here's what a "healthy" file (e.g. https://archive.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-00-40-08-mozilla-aurora-android-x86/fennec-46.0a2.multi.android-i386.txt) looks like:: 20160221004008 https://hg.mozilla.org/releases/mozilla-aurora/rev/97126e4bc6380071750a619dbad4f5d174df2f46 The second line is the revision. But https://archive.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-03-03-40-mozilla-central-android-api-15/fennec-47.0a1.multi.android-arm_info.txt does not have a revision. Note also, that this file has the structure we normally expect from NON-nightlies. I.e. `Key=Value\nKey2=Value2` So perhaps the bug is that this release's _info.txt file has the value of a non-nightly.
Blocks: 1249992
This is currently breaking Socorro's ftpscraper. See the see-also bug.
Any idea where this file is created? I can't seem to find it in factory.py, or anywhere else. And how come Android requires a different format from everything else? Maybe we should try to just switch this to use the json file, since that has both the revision and buildid.
Flags: needinfo?(rail)
IMO, don't use those txt files at all. They are archaic and we keep them only to avoid breaking things. If this is something new, use json files instead. Does https://archive.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-00-40-08-mozilla-aurora-android-x86/fennec-46.0a2.multi.android-i386.json contain all needed information?
Flags: needinfo?(rail)
See Also: → 1250142
I'm told this is screwing up crash reports for Beta, so I'm looking at how we can fix the currently offending file(s) as a one-off. Can we also get a bug on file about fixing the scraper not to die if it encounters a bad file? Bustage like this on Nightly is bound to happen sometimes, and it's unfortunate that it affects releases.
We started generated those files recently in bug 1248883, so deleting them from S3 won't help.
See Also: → 1248883
(In reply to Rail Aliiev [:rail] from comment #6) > We started generated those files recently in bug 1248883, so deleting them > from S3 won't help. As a one-off for today it will, I think? Obviously it's not a long term fix. (In reply to Ben Hearsum (:bhearsum) from comment #5) > Jeremy, can you delete the offending files from S3? I don't think I have > access to do that. Specifically: > https://archive.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-03-03-40- > mozilla-central-android-api-15/fennec-47.0a1.multi.android-arm_info.txt > https://archive.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-03-03-40- > mozilla-central-android-api-9/fennec-47.0a1.multi.android-arm_info.txt > https://archive.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-03-03-40- > mozilla-central-android-x86/fennec-47.0a1.multi.android-i386_info.txt Just noticed that this affects all products, and not just on the 21st. Hold off on this for the moment, I need to make a list of all the files after the currently nightlies finish.
Flags: needinfo?(oremj)
Here's the complete list of files that need deleting. To be clear, I'm only requesting this as a one-off fix for today. It's not reasonable to do this on a continuing basis: http://ftp.mozilla.org/pub/b2g/nightly/2016/02/2016-02-21-03-02-07-mozilla-central/firefox-47.0a1.en-US.win32_info.txt http://ftp.mozilla.org/pub/b2g/nightly/2016/02/2016-02-21-03-02-07-mozilla-central/graphene-47.0a1.en-US.linux-x86_64_info.txt http://ftp.mozilla.org/pub/b2g/nightly/2016/02/2016-02-21-15-02-14-mozilla-central/firefox-47.0a1.en-US.win32_info.txt http://ftp.mozilla.org/pub/b2g/nightly/2016/02/2016-02-21-15-02-14-mozilla-central/graphene-47.0a1.en-US.linux-x86_64_info.txt http://ftp.mozilla.org/pub/b2g/nightly/2016/02/2016-02-22-03-02-39-mozilla-central/firefox-47.0a1.en-US.win32_info.txt http://ftp.mozilla.org/pub/b2g/nightly/2016/02/2016-02-22-03-02-39-mozilla-central/graphene-47.0a1.en-US.linux-x86_64_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-21-03-03-40-mozilla-central/firefox-47.0a1.en-US.linux-i686_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-21-03-03-40-mozilla-central/firefox-47.0a1.en-US.linux-x86_64_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-21-03-03-40-mozilla-central/firefox-47.0a1.en-US.mac_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-21-03-03-40-mozilla-central/firefox-47.0a1.en-US.win32_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-21-03-03-40-mozilla-central/firefox-47.0a1.en-US.win64_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-22-03-02-12-mozilla-central/firefox-47.0a1.en-US.linux-i686_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-22-03-02-12-mozilla-central/firefox-47.0a1.en-US.linux-x86_64_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-22-03-02-12-mozilla-central/firefox-47.0a1.en-US.mac_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-22-03-02-12-mozilla-central/firefox-47.0a1.en-US.win32_info.txt http://ftp.mozilla.org/pub/firefox/nightly/2016/02/2016-02-22-03-02-12-mozilla-central/firefox-47.0a1.en-US.win64_info.txt http://ftp.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-03-03-40-mozilla-central-android-api-15/fennec-47.0a1.multi.android-arm_info.txt http://ftp.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-03-03-40-mozilla-central-android-api-9/fennec-47.0a1.multi.android-arm_info.txt http://ftp.mozilla.org/pub/mobile/nightly/2016/02/2016-02-21-03-03-40-mozilla-central-android-x86/fennec-47.0a1.multi.android-i386_info.txt http://ftp.mozilla.org/pub/mobile/nightly/2016/02/2016-02-22-03-02-12-mozilla-central-android-api-15/fennec-47.0a1.multi.android-arm_info.txt http://ftp.mozilla.org/pub/mobile/nightly/2016/02/2016-02-22-03-02-12-mozilla-central-android-api-9/fennec-47.0a1.multi.android-arm_info.txt http://ftp.mozilla.org/pub/mobile/nightly/2016/02/2016-02-22-03-02-12-mozilla-central-android-x86/fennec-47.0a1.multi.android-i386_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-21-03-02-13-comm-central/thunderbird-47.0a1.en-US.linux-i686_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-21-03-02-13-comm-central/thunderbird-47.0a1.en-US.linux-x86_64_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-21-03-02-13-comm-central/thunderbird-47.0a1.en-US.mac_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-22-03-02-49-comm-central/thunderbird-47.0a1.en-US.linux-i686_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-22-03-02-49-comm-central/thunderbird-47.0a1.en-US.linux-x86_64_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-22-03-02-49-comm-central/thunderbird-47.0a1.en-US.mac_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-22-03-02-49-comm-central/thunderbird-47.0a1.en-US.win32_info.txt http://ftp.mozilla.org/pub/thunderbird/nightly/2016/02/2016-02-22-03-02-49-comm-central/thunderbird-47.0a1.en-US.win64_info.txt Jeremy, can you help us out here?
Flags: needinfo?(oremj)
I'll clean these up.
Flags: needinfo?(oremj)
Cleanup done.
Assignee: nobody → oremj
Can this be closed out?
Flags: needinfo?(bhearsum)
Unless Kairo finds otherwise reasons, I believe we're done here. Socorro now reads the available .json file instead for mobile. And this has now been running successfully in production for the past ~12 hours.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bhearsum)
Resolution: --- → FIXED
(In reply to Peter Bengtsson [:peterbe] from comment #12) > Unless Kairo finds otherwise reasons, I believe we're done here. > > Socorro now reads the available .json file instead for mobile. And this has > now been running successfully in production for the past ~12 hours. Awesome, thanks for doing this Peter!
You need to log in before you can comment on or make changes to this bug.