Maintain the solution file persisting dependency information on
disk but update the runtime representation to
Gem::Resolver::DependencyRequest instances which are expected
by the sets when locating matches.
Properly abide by prerelease setting in customized sets and
force prerelease matching when in the builtin set. If a request
is matched on a prerelease, and the request itself is not set
to allow prereleases, update it to ensure successful resolution.
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 initializing for internal plugin resolution inspect contraints
on all defined dependencies. If a prerelease constraint is detected,
automatically enable prerelease resolution.
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 PR is dependent on the 2.1.0 release of the vagrant_cloud
library. It updates the `cloud` command to use the new interface
for interacting with the Vagrant Cloud API. It also adds support
for direct to backend storage uploads, and defaults to this
method.
Also included is a bit of cleanup refactoring, addition of method
documentation, and fixing up some small issues around custom username
usage within the internal client for authentication.
Passwords are (and should) never stored be as part of folder data.
I think there is also a case to be made about desensitizes
information here can lead to leaking of credentials. For example if
an exported folder is named "vagrant" and the users password is
"vagrant", the synced_folder cache will show "****" in place of the
folder name, indicating that it is also password.