- By the way: Trim the generate 'pip install' command in Ansible::Cap::Guest::Pip::pip_install
- GH-11048: Fix same regression for FreeBSD and SuSE guests.
- GH-6633: Add RSpec examples to cover ansible_local 'cap' code.
Note: RedHat/Fedora guests are not covered yet by unit tests.
Prior to this commit, if you ran Vagrant in a different current working
directory other than where a current guest machines location is, the
file provisioner would not take into account the machines local dir, and
would instead use the path where Vagrant was invoked to expand the
`source` path option for a file provisioner. This commit fixes that by
passing the root path `machine.env.cwd` when expanding the source dir.
Prior to this commit, the `pip_install_cmd` option for ansible guest
config was not properly finalized. This commit ensures that if that
value is still UNSET_VALUE, it gets set to empty string in the finalize!
method.
Prior to this commit, the chef_installed capability was looking for a
string that has recently changed in newer versions of chef. This commit
fixes that by instead just looking for the right version that was
configured for the chef client, rather than the specific string that
could change again in the future.
This update was prompted by updates in openssh to the scp behavior
making source directory paths suffixed with `.` no longer valid
resulting in errors on upload. The upload implementation within
the ssh communicator has been updated to retain the existing
behavior.
Included in this update is modifications to the winrm communicator
so the upload functionality matches that of the ssh communicator
respecting the trailing `.` behavior on source paths. With the
communicators updated to properly handle the paths, the file
provisioner was also updated to simply apply previously defined
path update rules only.
Fixes#10675
Adds a `reboot` option which allows the guest to be rebooted after
the completion of a shell provisioning task. The guest must support
the `:reboot` capability. Like the `reset` option, the `reboot`
option may be provided without defining `inline` or `file` options
when a reboot may be required between other provisioners.
Fixes#8639
Prior to this commit, the puppet provisioner would not properly set its
environment variables, if any were configured in the Vagrantfile. This
commit separates those properly with semicolons when calling out to
puppet apply.
The base chef provisioner class will set the node name automatically
if not provided in the configuration. Since the chef apply provisioner
does not provide a node_name option, setting it will invalidate the
configuration. This checks for the node name before attempting to
use it.
Fixes#9901
This commit sets the structured_facts option to nil if its still
UNSET_VALUE at the finalize step. This was causing a bug when the facter
config was set but was not using structured facts.
This bug (invalid method call) hasn't been caught by unit tests because
Vagrant::Plugin::V2::Config catches all invalid/bad configuration calls
and save them for generating error messages during the "validate" stage.
This way, the `ask_sudo_pass=(value)` method was not interrupted and the
`@ask_become_pass` attribute was (surprisingly) correctly set (allowing
the related unit tests to pass).
In order to avoid similar problem to happen again, the deprecation
message output is now fully verified.
Vagrant will verify that the current Ansible version does support the
requested compatibility mode (only applicable if not "auto", of course).
As mentioned in the documentation, there is no sanity checks between
`version` option and `compatibility_mode` option.
With this change, the host-based provisioner is also improved to
execute only once the "ansible" command (and store the gathered
information for multiple usages like version requirement and
compatibility checks). On the other hand, the guest-based provisioner
can still potentially execute "ansible" twice (once in the
AnsibleInstalled cap, and via "gather_ansible_version" function via
Base::set_compatibility_mode).
Before this change, only the ansible_local provisioner supported this
option (for ansible version requirement, and pip installation). Now, the
ansible host-based provisioner can also require a exact ansible version.
Resolve#8914
Note: this has been added as part of #6570 resolution, since the
introduction of the `compatibility_mode` auto-detection made both
provisioners made capable to detect ansible version.
Pending: optimize the code to avoid duplicated executions of "ansible
--version" command.