Closed Bug 616512 Opened 9 years ago Closed 9 years ago
partner repacks fail to upload if 'unsigned' directory doesn't exist yet
I hit this today during 3.6.13build3.
Priority: -- → P3
For anyone else doing a double-take, you can hit this for non-windows partner builds because they complete faster than the vanilla win32 does.
I think the best solution to this is to have unsigned platforms upload their partner repacks to 'partner-repacks', rather than 'unsigned/partner-repacks'. This will prevent an unnecessary re-upload to staging after signing.
(In reply to comment #2) > I think the best solution to this is to have unsigned platforms upload their > partner repacks to 'partner-repacks', rather than 'unsigned/partner-repacks'. > This will prevent an unnecessary re-upload to staging after signing. If we do this, please make sure the signing logic for partner repacks is verified/updated. We move partner repacks around a bit currently since we expect them under unsigned/.
9 years ago
9 years ago
No longer blocks: 478420
I'm digging around the partner scripts for bug 614227, I'll see if I can fix the rsyncs while I'm in there.
Assignee: nobody → bhearsum
The rsync that pulls in partner repacks from "unsigned" needed adjusting. Tested this with 3.6.14.
Attachment #509161 - Flags: review?(catlee)
D'oh, this was supposed to go in bug 614227. Doesn't really matter since the patches from it fix this bug, too.
Attachment #509161 - Flags: checked-in+
After the next reconfig we'll be all done here
Made it to production last week.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.