When the installer builder is called from the system shell (cmd.exe) using a command like the following:
InstallerBuilder "D:\NI Installer Builder\INSTALLERPROJECT.iip" -Build -Log "D:\NI Installer Builder\niib.log"
It spawns a background process and the application returns with a successful run BEFORE the installer is created. As the build is started in a background and a detached process; any build automation frameworks such as bamboo, jenkins, chef, etc. cannot monitor it's creation. This results in a failed operation a breaks continuous integration systems.
As a work around I have built a light python solution that monitors for a que event; in this case a
file either being populated or updated. I am using this application to monitor the log file as a que.
The python file should be attached to this submission.
Basically:
1. InstallerBuilder is ran – begins running building process in the background
and returns successful process run before installer is constructed.
2. IndirectProcessMonitor.py is ran (max timeout and file set):
python IndirectProcessMonitor.py 300 “D:\NI_installerbuilder\niib.log”
NOTE: Probably could set it to your setup file as well
3. IndirectProcessMonitor.py returns when timeout is exceeded or que file is
created or updated.
If the NI installer builder is to be able to be dropped into any automation
frameworks this has to be fixed on NI’s end. If this bug/support is scheduled
for development I’d be interested to know as it will/should break our
workaround.
