Inspect the error message received when failing to install a
plugin. If it's something we can determine the cause, send
back a cleaner error message to the user on how to resolve.
During a plugin install, if the plugin is already installed and
activated, no specification will be returned as there was nothing
new installed. In this situation, look for the requested plugin
within the activated specifications. If it is found, then proceed
since the plugin is installed. If it is not found, return an error.
Adds method to shared helpers for adding procs to be evaluated
which can add default modifications to the option parser used
by commands. Customized option parser class within Vagrant
handles processing defined procs to set options.
This adjusts how triggers are implemented during a normal run. Any
defined triggers which are applicable are located and injected into
the run stack as the stack is built, including hook type triggers.
Support is included for dynamic hook lookup.
The data type used when defining triggers has also been relaxed to
support symbols, strings, or constants.
This pull request adds an enhancement to the internal Bundler class
to cache solution sets. This prevents Vagrant from generating a
solution for configured plugins on every run. Modifications to
the configured plugin list (global or local) will result in the
cached solution being invalidatd and resolved again.
Also included is the removal of the GEMRC modifications required
for Windows.
When the provider supports parallel actions and actions are being
run in parallel, do not immediately kill the process on failure.
Instead terminate the action thread and log the exit code. Once
all running actions have completed, the process will then exit
with the stored exit code.
Prior to this commit, if a guest name was given as a symbol, the
filter_triggers method would fail to properly match it with the only_on
option, as it is not a valid type to the #String.match method. This
commit fixes that by converting the parameter to a string so that it can
be properly matched on the guest.
Prior to this commit, the `abort` option for triggers would just call
`exit`, which would end up raising a SystemExit exception, signaling
Vagrant to abort. This broke down however in a multithreaded context
like when running multiple guests at once on supported providers,
resulting in Vagrant failing to exit cleanly and instead raise an
exception. This commit changes that by instead using `Process.exit!` to
abort Vagrant.
This commit introduces some basic functionality for typed triggers:
- command
- action
Command triggers are triggers that will run before or after a given
sub-command.
Action triggers are for running triggers before or after internal
actions for Vagrant. This could be before or after a provision step,
before or after synced folders, or networking, etc.
