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 trigger
config.trigger.after :up do |trigger|
...
end

# multiple commands for this trigger
config.trigger.before [:up, :destroy, :halt, :package] do |trigger|
...
end

# or defined as a splat list
config.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 trigger
config.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"}
  end
end

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 4
end

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.