If the provider does not include a metadata.json file prior to
compressing the box, determine current provider and write
metadata.json file before compressing.
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.
This commit adds a new flag to the `vagrant validate` command which
allows users to completely ignore the provider block of a config file.
This is useful for when you are running `vagrant validate` in CI and
don't want to install a valid provider to check the syntax of your
Vagratnfile. When the flag is invoked, a warning will be displayed
saying that the provider block will be ignored and not validated.
Prior to this commit, vagrant would halt if it could not parse the
metadata file for a box to check for updates with. This commit changes
that to behave like when vagrant fails to download a metadata file and
continue on but warn the user it failed to check for box updates.
Prior to this commit, when the `--global` flag was used with the
`vagrant box outdated` command, it would ignore box providers and not
inform the user of all outdated boxes. This commit fixes that by
displaying each box within the users environment, and includes the
provider of the box in the message.
Prior to this commit, if a user ran the `vagrant ssh -c CMD` command, it
would not allow the user to configure pseudo-terminal allocation. This
commit introduces a -t flag for the `vagrant ssh` command which defaults
to true if not specified.
Prior to this commit, if a user set a URL for the name of a box, vagrant
would not warn the user about using box_url instead. This would lead to
some difficult user experiences around the various box commands due to
the box name being a full URL. This commit introduces a warning to the
user and lets them know to instead use box_url.
This updates the behavior of the provision action to never run a provisioner
that is specified to "never" run unless it has been explicitly requested. Also
adds test coverage to the provision action.
Currently, the supported way (see GH#1922) to disable the default port
2222 port forward is:
config.vm.network :forwarded_port, guest: 22, host: 2222, disabled: true
However, the port collision detection runs on all ports, regardless of
the `disabled` flag. This leads it to attempt to connect to port
2222, notice it is taken, and abort with a port conflict -- even
though it will not be attempting to use the port at all.
Skip disabled ports when doing port conflict detection.
A workaround that does not require a Vagrant upgrade to one containing
this fix is to instead set `auto_correct` on the disabled port:
config.vm.network :forwarded_port, guest: 22, host: 2222, disabled: true, auto_correct: true
This allows the disabled port to be reshuffled off to some other
unused port.
This commit separates the scratch and output directory creation from the
main package middleware into its own PackageSetupFolders middleware.
Additionally, the validation that ensures an output file does not exist
is moved into a validation function that can be shared across multiple
methods.
This refactor permits a pre-flight check to ensure box packaging would
be successful before actually stopping the VM.
Fixes GH-7351
This commit bumps the box resume delay time to 24h and makes it a
constant because I had a bugger of a time actually finding this in the
code :frowny:.
Fixes GH-7272
Added support for Port forwarding in an IP aliased environment. The change
makes the following forwarding rule(s) possible.
Ex: eth0 is ip aliased to have a range of IP addresses 10.20.30.0/24.
In the Vagrant file, we can now have an entry like the following and
it will just work! Note the host port 8081 is the same for both .1 and .2.
Vagrant.configure("2") do |config|
config.vm.network "forwarded_port", guest: 80, host: 8080
config.vm.network "forwarded_port", guest: 81, host: 8081, host_ip: 10.20.30.1
config.vm.network "forwarded_port", guest: 82, host: 8081, host_ip: 10.20.30.2
end
This helps with some confusion caused in GH-2538, since the output says:
> Running cleanup tasks for 'shell' provisioner...
But that's actually not true. It is running the cleanup tasks iff the
provisioner defined a cleanup task. This commit changes the
provisioner_cleanup middleware to only run cleanup tasks if the subclass
defines a cleanup task.
The reason we can't just check if the provisioner `respond_to?` the
`cleanup` method is because the parent provisioner base class (which
all provisioners inherit from) defines a blank cleanup method. This is
important because it means we never risk calling an unimplemented
cleanup function, and it also helps define the public API for a
provisioner.
