Closed Bug 686337 Opened 10 years ago Closed 7 years ago
Android nightly builds should download the previous
.apk *before* uploading a new gecko-unsigned-unaligned .apk to the same URL
Well, I don't really know if it's intermittent, I just assume everything is. https://tbpl.mozilla.org/php/getParsedLog.php?id=6374752 Android mozilla-central nightly on 2011-09-12 03:08:43 PDT for push 569a45bfb71c command: START command: wget -O previous.apk http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-android/gecko-unsigned-unaligned.apk command: cwd: /builds/slave/m-cen-lnx-andrd-ntly/build command: output: --04:19:08-- http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-android/gecko-unsigned-unaligned.apk Resolving ftp.mozilla.org... 184.108.40.206 Connecting to ftp.mozilla.org|220.127.116.11|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 16307815 (16M) [application/vnd.android.package-archive] ... 04:19:10 (11.1 MB/s) - `previous.apk' saved [16307815/16307815] command: END (1.48s elapsed) Traceback (most recent call last): File "/builds/slave/m-cen-lnx-andrd-ntly/tools/scripts/android/android_snippet.py", line 246, in <module> main() File "/builds/slave/m-cen-lnx-andrd-ntly/tools/scripts/android/android_snippet.py", line 233, in main options.download_subdir) File "/builds/slave/m-cen-lnx-andrd-ntly/tools/scripts/android/android_snippet.py", line 172, in getPreviousBuildID return parseApk('previous.apk') File "/builds/slave/m-cen-lnx-andrd-ntly/tools/scripts/android/android_snippet.py", line 93, in parseApk appini = StringIO(zipfile.ZipFile(apk_filename).read('application.ini')) File "/tools/python-2.5.1/lib/python2.5/zipfile.py", line 346, in __init__ self._GetContents() File "/tools/python-2.5.1/lib/python2.5/zipfile.py", line 366, in _GetContents self._RealGetContents() File "/tools/python-2.5.1/lib/python2.5/zipfile.py", line 378, in _RealGetContents raise BadZipfile, "File is not a zip file" zipfile.BadZipfile: File is not a zip file program finished with exit code 1
Retriggered it, so perhaps we'll know if it's intermittent in an hour or so.
John, can you look into this?
Assignee: nobody → jhford
a) we upload fennec b) we download the "previous" gecko-unsigned-unaligned.apk This is the wrong order. What's probably happening is post_upload.py is in the middle of copying the file into the latest directory when we try to download it and pretend it's the previous apk. If we keep this order, we can just use the existing files on disk since downloading the same bits we just uploaded is silly. If we reverse the order, we'll actually get the previous apk's buildid.
Also, we may be getting rid of the gecko-unsigned-unaligned.apk file entirely. Since we already know the version and filename of existing fennec, we can try to grab the same thing from ftp instead.
Phil, have you seen this happen again? I suggest marking this as WORKSFORME if we haven't seen this happen again in 7 months.
Putting this bug back in the pool. I haven't had a chance to look into this bug yet, so I have no insight into the solution.
Assignee: jhford → nobody
Component: Release Engineering → Release Engineering: Platform Support
Priority: -- → P3
QA Contact: release → coop
Whiteboard: [triagefollowup] → [mobile]
(In reply to Aki Sasaki [:aki] from comment #5) > Also, we may be getting rid of the gecko-unsigned-unaligned.apk file > entirely. > Since we already know the version and filename of existing fennec, we can > try to grab the same thing from ftp instead. aki, joel, philor: I can't say I've ever noticed this error in my work so far, so I want to make sure it is still an issue before I devote any of my cycles to looking into this, rather than WFM/WONTFIX. Do any of you have insight?
See comment 7.
well, I haven't seen it, but comment 7 does make some sense.
Product: mozilla.org → Release Engineering
I can pick this up in a month or so (end of July 2014) when I clear the higher priority items on my plate. I appreciate comment 7 explains there is a problem (thanks Aki for looking into this) but am just curious why we don't see it more often. Do we have an explanation for this? Or maybe it is happening frequently and this bug is not getting updated? Philor, what are your thoughts? Pete
Summary: Intermittent "zipfile.BadZipfile: File is not a zip file" downloading previous.apk in android_snippet.py → Android nightly builds should download the previous.apk *before* uploading a new gecko-unsigned-unaligned.apk to the same URL
I think we should just WONTFIX this, and rip out all the snippet upload steps for Nightly/Aurora builds (both desktop and mobile). We've transitioned to Balrog now, and the only reason to keep uploading to AUS2 is some sanity checks post bug 748698.
(In reply to Nick Thomas [:nthomas] from comment #14) > I think we should just WONTFIX this, and rip out all the snippet upload > steps for Nightly/Aurora builds (both desktop and mobile). We've > transitioned to Balrog now, and the only reason to keep uploading to AUS2 is > some sanity checks post bug 748698. Can we do this? My yak looks like: I don't want to generate and upload gecko-unsigned-unaligned.apk; it's used in android_snippet.py; android_snippet.py is not relevant anymore. nthomas: can you comment on the technical details of removing this snippet generation stuff?
nthomas: I've moved this discussion to Bug 1063966, which is my actual issue.
I'm going to WONTFIX this, since this code is going to go away in bug 933426.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.