This addresses the surprising behavior that the StoreBoxMetadata hook
was running many times during a machine up, including during failed
operations where a destroy_on_error deleted the machine. This was
resulting in an error that looked like:
> No such file or directory @ rb_sysopen [...] /[...]/box_meta
Plugin action hooks using prepend/append were attaching every time a
Builder was run, including sub-Builders that show up for things like
Call actions.
To fix this, we tell Builders if they are "primary" and only run
prepend/append on those. See inline comments for more explanation.
The raw action name tracking should be sufficient for preventing
multi-insertions where only a single modification should occur.
With action name, hooks _should_ be able to be applied in multiple
builder stacks as they are expanding.
Fixes#12035
The raw actions are used for applying the original trigger behavior
which can insert before and/or after the entire set of actions. When
processing the stack items, mark when the raw action has been applied
to prevent it from being applied again. Triggers around the raw actions
should only ever be applied _once_.
Fixes#12034
When expanding stack track the origin action name and only apply
it once the stack has completed its expansion. The local env data
is marked with origin action to prevent it from being applied in
nested builders as they are expanded. The value of the stored action
name is checked and invalidated if another action is applied to the
same env in the future so hooks / triggers for that action are
applied as expected.
This includes updates for resolving all warnings provided by Ruby
for deprecations and/or removed methods. It also enables support
for Ruby 2.7 in the specification constraint as all 2.7 related
warnings are resolved with this changeset.
These updates allow the after trigger to behave the same as the
original with regards to the execution location of the trigger
within the execution stack.
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.
The RDoc comments for `Vagrant::Action::Builder#to_app` reference an
instance of `Vagrant::Action::Environment` as the passed paramter. There
is no class `Vagrant::Action::Environment` available. The param being
passed is actually a `Hash` that represents the "action environment".
This commit corrects the RDoc lines for
`Vagrant::Action::Builder#to_app` to correctly reference the passed
`Hash`.
The issue here is that when a middleware failed and a recovery sequence
started, it would halt at the "call" step because the "Call" didn't
properly recover the child sequence.
An additional issue was that a Warden had no "recover" method, meaning
embedded Wardens wouldn't recover their stacks properly.
