- 24 Sep, 2014 1 commit
-
-
Shawn Neal authored
We need to ensure the VMWare process has exited before attempting to run VMX file cleanup steps, otherwise VMWare may overwrite our changes. While Packer does its best to ensure VMWare has exited, there's still a race condition on some OSs between VMWare flushing the VMX and Packer updating it. The workaround is to artifically wait 5 seconds. When using the VMX builder its possible for the source machine to have a floppy and/or CD-ROM mounted which gets cloned to the new VM Packer spins up, but have no Packer configuration for those devices. With this change we always attempt to remove the mounted devices regardless of the Packer configuration.
-
- 17 Sep, 2014 1 commit
-
-
Shawn Neal authored
When using the VMX builder its possible for the source machine to have a floppy configured which gets cloned to the new VM Packer spins up. When the new VM's Packer config doesn't have a floppy_files config entry, the Packer clean VMX step fails to remove the floppy disk from the new VM. This can cause build failures, for example with the vsphere post processor; generating errors like: * Post-processor failed: Failed: exit status 1 Error: File (/home/teamcity/tmp/buildTmp/packer941120499) could not be found. Opening the cloned VM's VMX file you can clearly see it has a floppy entry from the source machine's VMX file (exact same path) even though the Packer config contains no floppy_files entry.
-
- 15 Sep, 2014 1 commit
-
-
Jason A. Beranek authored
fixed vmware-vmx step order
-
- 14 Sep, 2014 1 commit
-
-
John Deatherage authored
-
- 12 Sep, 2014 1 commit
-
-
Mitchell Hashimoto authored
Run two builds in parallel with go get
-
- 11 Sep, 2014 6 commits
-
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mathias Meyer authored
By default, go get determines parallelism based on the number of cores available. Those show up as 32 in the Travis CI environment but a virtual machine is limited both by the amount of cores it has allocated and the amount of memory available to it. 32 parallel build processes are likely to exhaust the memory resources, leading to killed processes. This change reduces the number of builds running concurrently to 2, which should reduce the likelihood of memory exhaustion greatly. The number could probably be dialed up a little bit, but this should give a good default reflecting the environment's resources.
-
Mitchell Hashimoto authored
-
- 10 Sep, 2014 10 commits
-
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
website: Add group_vars and host_vars to Ansible provisioner docs
-
Chris Spicer authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Ross Smith II authored
-
Ross Smith II authored
-
Ross Smith II authored
-
- 09 Sep, 2014 2 commits
-
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
- 08 Sep, 2014 17 commits
-
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
(configs to disable will come next)
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
Config Dir and plugin discovery there
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
Merge branch '1064-fix-upload-file-permissions' of github.com:rasa/packer into rasa-1064-fix-upload-file-permissions Conflicts: builder/parallels/common/step_upload_parallels_tools.go builder/vmware/common/step_upload_tools.go provisioner/chef-client/provisioner.go provisioner/chef-solo/provisioner.go
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-
Mitchell Hashimoto authored
-