-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Question: Powershell Provisioner #706
Comments
Hi @jmos5156! It's better to run validation scripts after all the software is installed to make sure one tool didn't break the others in terms of PATH, env. variables, etc. We've seen that many times when the tool itself worked just fine right after the installation, but at the end of the build it was broken |
Just an idea, we can run tests twice:
cc: @alepauly , switching to Pester for image testing can help a lot with it |
I'd agree with the pester testing as this is something I've done before with Powershell DSC. Running this at the end of an image creation can help to tick the boxes of installs affecting others. However, going back to @miketimofeev Furthermore, for what I need, I do not need all the packages on offer. Several versions of Python etc, are not needed and delay/add further points of failure. I make this point here #507 (comment), where I suggest that the packer file could be used to allow people more control over what gets installed and the versions that do without affecting the install scripts. I strip out entire swathes out of the Packer file for my needs. In doing so I have hit issues along the way with dependencies etc... hence why I ask about organizing installs, validations, and basic software together. There are certain installs that I feel should be grouped together, or considered the 'basics' ie. 7-zip. notepad++, Azure Cli, Powershell, NPM. These are software that other installs depend upon and should be available on all agents. I'd personally add this in the initialize phase but list them as follows
The suggestion I make above is more about organizing the installs in a modular way that anyone can contribute from their hours of testing without it affecting up/downstream installs, as with my other post (see above) give more control and flexibility to users of this repo get more successful builds. |
Thank you for your suggestions. The both, testing approach and modular structure, make sense to us. I am closing this issue for now but feel free to share any additional thoughts / proposals. |
Hello...
I've been using this repo now for a while and have always wondered if there was any reason why the install and validate scripts are based in different sections of the packer files in the same provisioner section.
For exampled we have
separate from each other. I cannot see a reason for this but I wonder if this would not be a better layout for future maintenance?
I suggest this as I'd want to know if an install had failed before continuing on to hours more installs only for the process to fail at its validate stage found later on in the script.
The text was updated successfully, but these errors were encountered: