Closed Bug 1011501 Opened 6 years ago Closed 6 years ago
eng+noneng nightlies upload MARs (and maybe other files) that stomp on each other
Found this out when I tried to update. Balrog metadata has: <patch type="complete" URL="http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/b2g-flame-gecko-update.mar" hashFunction="sha512" hashValue="af1a33c4e2a8a26755f5ca77f5cc415770ccc3afdb746d78d8721aa214f989594541f02a9b046874a1193ef7adfbd7b7fd71b144849e69e29b71e60716d58057" size="59397309"/> The files from the latest two nightlies on FTP are: 58c255228c267374366a122a713e032d08debbca265a8617a87d17a385e544019329b17fa4843dc6660f109215f4d612eb7e111385ba904d5590c797eb95bb02 latest-mozilla-central/b2g-flame-gecko-update.mar 58c255228c267374366a122a713e032d08debbca265a8617a87d17a385e544019329b17fa4843dc6660f109215f4d612eb7e111385ba904d5590c797eb95bb02 2014-05-16-04-02-03-mozilla-central/b2g-flame-gecko-update.mar db5ea10475256340442c493e9fa3b9f35135376bd6d30a57096f65bc177c9eeeafab41b715f635a9f24bb84eafa7eb6ed0ce6fbbc0bd885e010e0f156a579d15 2014-05-15-16-02-02-mozilla-central/b2g-flame-gecko-update.mar The file on disk on the slave that did the most recent nightly has: af1a33c4e2a8a26755f5ca77f5cc415770ccc3afdb746d78d8721aa214f989594541f02a9b046874a1193ef7adfbd7b7fd71b144849e69e29b71e60716d58057 b2g-flame-gecko-update.mar [firstname.lastname@example.org b2g-update]$ ls -l total 58008 -rw-rw-r-- 1 cltbld mock_mozilla 59397309 May 16 05:40 b2g-flame-gecko-update.mar The latest MAR on update.boot2gecko.org matches the one from the slave, however: af1a33c4e2a8a26755f5ca77f5cc415770ccc3afdb746d78d8721aa214f989594541f02a9b046874a1193ef7adfbd7b7fd71b144849e69e29b71e60716d58057 b2g_update_20140516040203.mar
The MAR in upload-public (the staging area for ftp uploads) for the last nightly doesn't match the MAR on FTP: af1a33c4e2a8a26755f5ca77f5cc415770ccc3afdb746d78d8721aa214f989594541f02a9b046874a1193ef7adfbd7b7fd71b144849e69e29b71e60716d58057 upload-public/b2g-flame-gecko-update.mar
I unpacked the two MARs and found this in some comments: -//@line 6 "/builds/slave/b2g_m-cen_flame_eng_ntly-00000/build/gecko/b2g/locales/en-US/b2g-l10n.js" +//@line 6 "/builds/slave/b2g_m-cen_flame_ntly-000000000/build/gecko/b2g/locales/en-US/b2g-l10n.js" So, eng and non-eng nightlies stomp on each other. Hooray!
Summary: flame checksum/filesize submitted to balrog doesn't match files on ftp → eng+noneng nightlies upload MARs (and maybe other files) that stomp on each other
So, eng nightlies upload to a different place within tinderbox-builds and on the private server. We should probably do the same for the nightly uploads to public FTP. I think appending something to %(branch)s in https://github.com/mozilla/build-mozharness/blob/master/configs/b2g/releng-otoro-eng.py#L33 would probably do it?
Basically, we're uploading to the same style dirs as we are to pvtbuilds with this patch applied. This may resolve bug 1011006, too. I'm not sure if this will break anything or not - I don't see any other references to these path in the mozharness configs in the mozharness repo nor gecko.
Attachment #8423940 - Flags: review?(aki)
Comment on attachment 8423940 [details] [diff] [review] upload b2g builds to target-specific directories on public ftp I think this will work. Could you also update releng-otoro.py and releng-fota-updates.py ?
Attachment #8423940 - Flags: review?(aki) → review+
(In reply to Aki Sasaki [:aki] from comment #5) > Comment on attachment 8423940 [details] [diff] [review] > upload b2g builds to target-specific directories on public ftp > > I think this will work. > Could you also update releng-otoro.py and releng-fota-updates.py ? I updated my local copy to do that - I'll probably wait until Tuesday to land, since Monday is a holiday for me.
Comment on attachment 8423940 [details] [diff] [review] upload b2g builds to target-specific directories on public ftp Landed, including the two files you mentioned.
Attachment #8423940 - Flags: checked-in+
This is in production, leaving this open until the next set of nightlies run...
It looks like this worked. The only updated files in http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/ are the b2g desktop builds, which is expected. We've now got a bunch of dirs for the device builds, like: http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame-eng/ http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central-flame/ http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2014-05-21-04-02-03-mozilla-central-hamachi-eng/ http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/2014-05-21-04-02-03-mozilla-central-hamachi/ I went ahead and removed the now-outdated device bits from latest-* - we're all done here.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.