This is the intended behavior but it is not obvious. When setting up synced
folders that require parent folders (e.g. folders that live in Go's `GOPATH`)
this has the potential to catch users off guard. See #2257.
Prior to this commit, the run trigger option wouldn't catch for failures
outside of the #Subprocess.execute raising exceptions. This commit fixes
that by inspecting the exit code result of the subprocess and using the
new `exit_codes` option to determine how to move forward with the
trigger.
`suspend` action is not listed, even though it can be used and it works.
```
$ vagrant --version
Vagrant 2.1.1
```
```
config.trigger.before [:suspend] do |trigger|
trigger.name = "Before suspend"
trigger.run = {inline: "..."}
end
````
- Fix#9796: Failing installation on bionic (18.04 LTS)
- Remove support for precise (12.04 LTS), which is out of public support
(On this version, the package python-software-properties contained
the add-apt-repository tool)
- Reduce the number of SSH calls, and avoid unnecessary apt-get calls.
The command should be stand-alone, not part of a "sentence":
```
Enable-WindowsOptionalFeature : A positional parameter cannot be found that accepts argument '.'.
At line:1 char:1
+ Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Enable-WindowsOptionalFeature], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.Dism.Commands.EnableWindowsOptionalFeatureCommand
```
- Remove undesired blank characters
- The examples attached to a specific option must be concise
- The original example is a tip for a non-standard use case
I either got:
`syntax error, unexpected ':', expecting '}` or `wrong number of arguments (given 1, expected 0) (ArgumentError)` until I added the `=` in.
To allow users to continue to use the community plugin, this commit adds
a switch that will not load the core trigger feature if it detects the
community plugin is installed. It also allows the user to disable the
warning so they can continue to use the plugin without extra output.
In the $script variable definition there appears to be a typo of "<<SCRIPT" when it should be "<<-SCRIPT". I ran into this issue while editing the Vagrant file on a Fedora variant with ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux].
Creating a usable box from scratch
- api only accepts puts no push when uploading the file
- the final step of actually releasing the version was missing from ruby example
Prior to this commit, the virtualbox synced folder option
`SharedFoldersEnableSymlinksCreate` was always enabled. This commit
introduces a config option and an environment variable which allows
users to configure the option globally or per synced_folder in their
Vagrantfile.
When using Turbolinks to navigate between docs pages, the document ready event never fired and all language examples were shown. This should fix the issue without needed a refresh/example menu click.
- Keep the Programming Errors with corresponding Exception class and
en.yml message template. Fix the alphabetical order in errors.rb by
the way.
- Fix English wording in the documentation and en.yml messages
- Use StandardError for unknown error rescuing.
Thanks @chrisroberts!
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).
Fixing a typo made in 073898046542323eb11c2e129f37fa558ae201e1,
after getting the confirmation that all the Vagrant docs will continue
to use full path for internal links (for the moment).
[ci skip]
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.
With this change, it is now possible to get rid of many deprecation
messages successively introduced in Ansible 1.9, and 2.0. More
interesting, the generated inventory will contain the recommended
variable names (e.g. `ansible_host` instead of `ansible_ssh_host`)
when the compatibility mode is set to '2.0'.
Details:
- Add `compatibility_mode` option to control the Ansible parameters
format to be used. The value corresponds to the minimal version
supported. For the moment, possible values are '1.8' (corresponding to
Vagrant's former behaviour) or '2.0'.
Note that a dynamic inventory generated in compatibility mode '2.0'
is not supported by Ansible 1.x. On the other hand, Ansible 2.x so far
supports inventory format generated by the compatibility mode '1.8'.
- Add compatibility mode auto-detection, based on the available Ansible
version. This is the default behaviour in order to bring a maximum of
user friendliness. The drawback of this approach is to let potential
compatibility breaking risks, for `ansible` provisioner setups that
already integrate Ansible 2.x **AND** rely on the existence of
the generated `_ssh` variable names. Thanks to the vagrant warnings
(and its release notes), I argue that it is worth to offer
auto-detection by default, which offers a sweet transition to most
users.
- Add `become`, `become_user` and `ask_become_pass` options and their
backwards compatible aliases. The legacy options are now deprecated.
Note that we intentionally didn't provide a '1.9' compatibility mode,
as it would add extra-complexity for practically no added-value.
To my knowledge, the Ansible 2.x series haven't introduced yet any major
changes or deprecations that would motivate to introduce a higher
version compatibility mode (to be confirmed/verified).
Resolve GH-6570
Still Pending:
- Optimization: Reduce the number of `ansible` command executions.
Currently two exec calls will be performed when the compatibility
mode auto-detection is enabled (i.e. by default). We could make the
provisioner a little bit smarter to only execute `ansible` only once
in any situation (by combining "presence" and "version" checks).
- User-friendliness: Add better validator on `compatibility_mode`
option, and shows a warning or an error instead of the silent
fallback on the auto-detection modus.
- Test coverage: All the added behaviours are not fully covered yet.
This commit aligns how the file provisioner should work on all host
machines. It ensures that a `/.` is only applied if the user intended
to upload a folder to a destination under a different name. It ensures
that if uploading to a windows guest with a different destination folder
name, it does not nest the source folder under that name so that it
works the same as it does on linux platforms. It also updates the
behavior of the winrm upload communicator by allowing an array of paths
to be uploaded instead of a single file or folder to allow for this new
functionality for windows guests.
This commit introduces the salt_arg option that allows a user to pass
additional command line flags to the `salt` tool when provisioning with
a master setup.
It also adds additional config validation to ensure that both
`salt_args` and `salt_call_args` is an array.
Prior to this commit, there was no way to add additional ssh arguments
within a Vagrantfile for a given vagrant machine. This commit introduces
a new option extra_args that allows users to pass in a single argument
or an array of flags that will be added onto the ssh command.