801175 - Partner repacks don't repack win32 builds sometimes?

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P5)

Description

[Chris AtLee [:catlee]]

I hit this when doing the funnelcake15/16 builds (bug 800551). I had a few false starts, and so by the time I got everything going, I hit the True part of this if statement:

http://hg.mozilla.org/build/partner-repacks/file/b57e518082db/scripts/partner-repacks.py#l729

which meant that the win32 installers got modified, but not resigned.

not sure if this was PEKBAC, setup issues, or other. filing for future investigation

Comment 1

[Chris AtLee [:catlee]]

Ben and I just figured out what happened here.

The repackSignedBuilds function basically extracts the original signed archive and repacks it into a new unsigned archive. We do this because we can't add files to the signed archive and re-sign it.

The first time I ran it, I didn't have signing set up properly. The original en-US file was downloaded, but then failed do this initial repack successfully. The next time I ran the script, repackSignedBuilds was never called since we already had the file. This meant that the partner repacks were modifying a copy of the original signed archive instead of a copy of the new unsigned archive. The future signing step then failed.

Possible fixes for this:
- Have repackSignedBuilds delete the local file if signing fails
- Have a distinct local path for the unsigned archives

P5 minor because we'll probably never hit this in our automation...

famous last words...