Skip to content

Remove duplication in installation scripts #44

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Feb 9, 2016
Merged

Conversation

elasticdog
Copy link
Owner

Instead of having mostly duplicate scripts for the entire installation process, we can split them up into the base installation steps and then run shell provisioners for anything specific to each of the types after the machine has rebooted.

This structure will mean less chance of error when making changes to machines, and will also allow for expansion of the scripts to be run at the end, such as adding a minimization script to remove history and clear out space on the drive before compression.

@rezonanc would you be able to confirm that Parallels builds still work with this reorganization? Using the script provisioner should ensure that there is not kernel version mismatch like you were worried about with your original PR.

Related to progress on #41

Instead of having mostly duplicate scripts for the entire installation
process, we can split them up into the base installation steps and then
run shell provisioners for anything specific to each of the types after
the machine has rebooted.

This structure will mean less chance of error when making changes to
machines, and will also allow for expansion of the scripts to be run at
the end, such as adding a minimization script to remove history and
clear out space on the drive before compression.
The upstream project is no longer hosted on SourceForge.
This is just for clarity when reading, and it seems to be the style that
the upstream documentation has finally settled on. No functional changes
here.
@elasticdog
Copy link
Owner Author

Of note, I noticed a surprisingly large drop in the size of the output box (like 702 MB -> 618MB), where this PR should not have introduced any real functional difference. My thought on the size difference is that because of some of the work now being down after the machine has been rebooted, perhaps various files are stored contiguously where they were scattered before, and thus compression is able to clean things up more efficiently. I'll be adding more cleanup steps in a later PR, but I did think this was a bit strange.

Anyway, I'd appreciate if someone else could run this branch and confirm that things work as expected before I merge.

@tomswartz07
Copy link
Collaborator

@elasticdog What was the 'reference' box created with and what version of Packer?
It looks like an update back in August improves the compression of boxes.

I've tested this branch with Virtualbox and it seems to check out. The unmodified build was 585MB.

@elasticdog
Copy link
Owner Author

@tomswartz07 I did end up updating from VirtualBox 5.0.10 to VirtualBox 5.0.14 in the middle of my testing, but had a constant Packer v0.8.6. I re-built things again after pushing this and I definitely still see a large size difference with this branch vs master...odd though that you and I seem to get slightly different sizes, although some upstream package changes could account for that.

Thank you for testing...I'll merge and start with the additional cleanup to see if my machine sizes get more consistent.

elasticdog added a commit that referenced this pull request Feb 9, 2016
Remove duplication in installation scripts
@elasticdog elasticdog merged commit 5c6cc81 into master Feb 9, 2016
@elasticdog elasticdog deleted the install-base branch February 9, 2016 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants