Closed Bug 616512 Opened 9 years ago Closed 9 years ago

partner repacks fail to upload if 'unsigned' directory doesn't exist yet

Categories

(Release Engineering :: General, defect, P3)

x86_64
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

References

Details

(Whiteboard: [automation][releases])

Attachments

(1 file)

I hit this today during 3.6.13build3.
Priority: -- → P3
Whiteboard: [automation][releases]
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/.
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: review?(catlee) → review+
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.