» Vagrant Triggers

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

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

  1. # single command trigger
  2. config.trigger.after :up do |trigger|
  3. ...
  4. end
  6. # multiple commands for this trigger
  7. config.trigger.before [:up, :destroy, :halt, :package] do |trigger|
  8. ...
  9. end
  11. # or defined as a splat list
  12. config.trigger.before :up, :destroy, :halt, :package do |trigger|
  13. ...
  14. end

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

  1. # single command trigger
  2. config.trigger.before :all do |trigger|
  3.   trigger.info = "Running a before trigger!"
  4.   trigger.ignore = [:destroy, :halt]
  5. end

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

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

  1. config.trigger.after :up do |trigger|
  2.   trigger.name = "Finished Message"
  3.   trigger.info = "Machine is up!"
  4. end
  6. config.trigger.after :up,
  7.   name: "Finished Message",
  8.   info: "Machine is up!"

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

  1. config.vm.define "ubuntu" do |ubuntu|
  2.   ubuntu.vm.box = "ubuntu"
  3.   ubuntu.trigger.before :destroy do |trigger|
  4.     trigger.warn = "Dumping database to /vagrant/outfile"
  5.     trigger.run_remote = {inline: "pg_dump dbname > /vagrant/outfile"}
  6.   end
  7. end

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

  1. Vagrantfile
  2.   global trigger 1
  3.   global trigger 2
  4.   machine defined
  5.     machine trigger 3
  6.   global trigger 4
  7. 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 theconfiguration section.