Merge lp:~brian.curtin/ubuntuone-windows-installer/build_installer into lp:ubuntuone-windows-installer
| Status: | Merged |
|---|---|
| Approved by: | Manuel de la Peña on 2012-05-17 |
| Approved revision: | 119 |
| Merged at revision: | 114 |
| Proposed branch: | lp:~brian.curtin/ubuntuone-windows-installer/build_installer |
| Merge into: | lp:ubuntuone-windows-installer |
| Diff against target: |
211 lines (+129/-31) 3 files modified
scripts/build_installer.py (+99/-0) scripts/setup.py (+30/-0) scripts/ubuntuone.xml (+0/-31) |
| To merge this branch: | bzr merge lp:~brian.curtin/ubuntuone-windows-installer/build_installer |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Manuel de la Peña (community) | Approve on 2012-05-17 | ||
| Roberto Alsina (community) | 2012-05-10 | Approve on 2012-05-16 | |
|
Review via email:
|
|||
Commit Message
- Automate the building and packaging of the Windows installer
Description of the Change
This branch adds build_installer.py which fully automates the creation of the BitRock installer. It includes the typical setup.py steps of fetch, prepare, and py2exe, then it runs the BitRock autoupdate and installer creation. Upon creation of the installer, it timestamps the installer name so we can identify which installers were created by the automation on which date.
Also included in the branch are changes which make the automation easier. The VistaLib DLLs are downloaded from my U1 rather than forcing a user to create an account on CodeProject, sign in, then download the zip file from there. The files are placed directly into dist/ where they are needed, along with the required license file.
A change was made to the setup.py file to package the CRT alongside the binaries rather than requiring the vcredist installer to be packaged in the installer and run. It makes the installer a bit quicker and it makes automation much easier.
| Manuel de la Peña (mandel) wrote : | # |
Here are some comments about the branch:
1. Imports are not in order, I personally don't care but I do know that members of the team like them to be in alphabetical order etc... can you please set them that way (I know, I know...)
2. _find_bitrock is a little fragile. The method is assuming that the package is going to be build in a x64 machine which might not be the case (I do not know the arch of the ec2 instance that runs jenkins). I think that a more 'robust' way to find bitrock will be looking in the registry. After installation I've noticed that you can find the installation path under HKEY_LOCAL_
The rest of the code looks great to me (I'm really looking foward to add a +1 to this and get automated builds in jenkins).
- 117. By Brian Curtin on 2012-05-17
-
Turn renaming off because Jenkins doesn't need a more unique path, just a predictable one. Removing the rename option also makes it easier to upload the resulting installer to a beta channel or something like that.
- 118. By Brian Curtin on 2012-05-17
-
Reorder imports
- 119. By Brian Curtin on 2012-05-17
-
Use the registry to determine BitRock's installation path rather than trying to discover it

+1 code review