Vagrant Triggers

As of version 2.1.0, Vagrant is capable of executing machine triggers before or after Vagrant commands.

Each trigger is expected to be given a command key for when it should be fired during the Vagrant command lifecycle. These could be defined as a single key or an array which acts like a whitelist for the defined trigger.

# single command triggerconfig.trigger.after :up do |trigger|...end # multiple commands for this triggerconfig.trigger.before [:up, :destroy, :halt, :package] do |trigger|...end # or defined as a splat listconfig.trigger.before :up, :destroy, :halt, :package do |trigger|...end

Alternatively, the key :all could be given which would run the trigger before or after every Vagrant command. If there is a command you don't want the trigger to run on, you can ignore that command with the ignore option.

# single command triggerconfig.trigger.before :all do |trigger|  trigger.info = "Running a before trigger!"  trigger.ignore = [:destroy, :halt]end

Note: If a trigger is defined on a command that does not exist, a warning will be displayed.

Triggers can be defined as a block or hash in a Vagrantfile. The example below will result in the same trigger:

config.trigger.after :up do |trigger|  trigger.name = "Finished Message"  trigger.info = "Machine is up!"end config.trigger.after :up,  name: "Finished Message",  info: "Machine is up!"

Triggers can also be defined within the scope of guests in a Vagrantfile. These triggers will only run on the configured guest. An example of a guest only trigger:

config.vm.define "ubuntu" do |ubuntu|  ubuntu.vm.box = "ubuntu"  ubuntu.trigger.before :destroy do |trigger|    trigger.warn = "Dumping database to /vagrant/outfile"    trigger.run_remote = {inline: "pg_dump dbname > /vagrant/outfile"}  endend

Global and machine-scoped triggers will execute in the order that they are defined within a Vagrantfile. Take for example an abstracted Vagrantfile:

Vagrantfile  global trigger 1  global trigger 2  machine defined    machine trigger 3  global trigger 4end

In this generic case, the triggers would fire in the order: 1 -> 2 -> 3 -> 4

For more information about what options are available for triggers, see the configuration section.