The main manifest may be a single file or a directory of .pp files.
docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html#with-puppet-master
https://github.com/mitchellh/vagrant/issues/4039
As this is nested in a powershell variable $command, it must be escaped
otherwise it is evaluated when the variable is created, giving an error that
"The term 'True' is not recognized as the name of a cmdlet, function,
script". This prevented using a puppet.working_directory on Windows.
Powershell doesn't understand the unix-style ENV=thing command syntax, the old vagrant-windows plugin monkey patched the provisioner to put semicolons between statements to set the variables before running puppet - this fixes the issue inside a windows? block leaving the normal non-windows code path working - therefore works for me on both unix and windows provisions with a facter block in place
It is common for Puppet to manage itself. If the puppet code you are
deploying pushes files to /etc/puppet/modules/, then prepending this
path can break deployment because it will override the module path if
the deployment code is changing. There is no good reason to include this
path. Puppet has built in defaults for this reason.
This mimics the equivalent feature from the chef_solo provisioner, and
mounts the puppet manifests and modules with NFS. Doing so can greatly
shortens the time of a puppet run if you have many .pp files.
Enabling this is optional. Virtualbox's (or any other provider's) shared
folders method stays the default. A typical usage would look like this:
config.vm.provision :puppet do |puppet|
puppet.manifests_path = "puppetmaster/manifests"
puppet.module_path = ["puppetmaster/modules"]
puppet.manifest_file = "site.pp"
puppet.nfs = true
end
This fixes#1308.
The sudo() block and/or the Puppet provisioner often returns newline
characters as separate strings. This makes the chomp() ineffective and
results in extraneous spacing between the output lines.
Separate out the call to chomp() so that we only do it once. Then only
output info if that line is not an empty string.
Previously, failures in applying the puppet manifests would be
ignored, because puppet apply/agent don't have any useful exit codes
by default. (Errors are printed, but vagrant continues.)
Use the option --detailed-exitcodes of puppet apply/agent to check for
success.