The local-exec push strategy was assuming it was running from a CLI and
so it wouldn't be a big deal for it to straight up `exec` and replace
its running with the user command. That command will just do its thing
and we want the exit code for the CLI command to match anyways, right?
Sure that works for a shell, but in a GRPC server setting it's decidedly
Not Cool to suddenly swap out the running process!
As you can imagine - the effect of doing this was all sorts of broken
pipes and unexpected EOFs and a very confused @phinze.
Luckily we had a subprocess strategy sitting right there for Windows
compat, so it was just a matter of switching to that in the server
context as well. Long and winding debugging process; simple fix;
just another classic!
When testing all of the push functionality I ran into the fact that the
FTP upload code did not recognize that I had VAGRANT_CWD set, so it
wasn't finding the right files to upload.
This should make everything work properly relative to that location.
When computing the solution set, if a gem is already loaded, make sure
to use the specification of the loaded one instead of the first
available as otherwise there is a risk that when multiple matches are
available the specification for the wrong version may be picked.
When this happens an error message will be triggered that looks like
can't activate json-2.3.0, already activated json-2.5.1
This can occur for distribution packaged vagrants as well as installs
for development purposes where the ruby install may contain a default
gem spec of an older version than is needed.
Fixes: #12521Fixes: vagrant-libvirt/vagrant-libvirt#1390
VirtualBox introduced a restriction on the valid range for hostonly
networks. When using a version of VirtualBox which includes this
restriction a check is performed on the defined IP address to validate
it is within either the default range (as defined in the VirtualBox
documentation) or the values defined in the network configuration
file.
SLE 11 does not ship systemd and then using systemctl poweroff does not
work. Therefore we fall back to using /sbin/shutdown for machines without
systemd.
This fixes https://github.com/hashicorp/vagrant/issues/12487
We have started seeing occasional shutdown failures on openSUSE Tumbleweed with
Virtualbox inside a qemu virtual machine, where `shutdown -h now` would return
nil. While the machine is successfully turned off, the command fails and vagrant
reports an error.
This commit changes the shutdown command to launch in the background which
also triggers a shutdown, but always succeeds.
When scrubbing box urls of access token parameters, only return
the processed URL if the access token was removed. If it was not
removed, return the original URL string. This prevents issues with
local file URLs being parsed and replaced with invalid paths.
Fixes: #12340#12350#12320
On *nix systems we might not have powershell installed and then finding
powershell.exe or pwsh.exe fails in some tests. If we instead mock
self.executable to return "powershell", then the tests pass and don't cause any
side effects.
