YAML tips

Tips and tricks for the most demanding

Aliases

Since Wordmove 2.2.0, you can take advantage of some YAML features such as aliases to avoid some config blocks duplication. See the example above:

global:
  sql_adapter: 'wpcli'

  default: &default # Default environment anchor for future reference
    vhost: "http://example.com"
    wordpress_path: "/var/www/your_site"
    paths: &paths # Paths anchor
      wp_content: "../app"
      plugins: "../app/plugins"
      mu_plugins: "../app/mu-plugins"
      uploads: "../app/uploads"
      languages: "../app/languages"
      themes: "../app/themes"
    database: &db # Database anchor
      host: localhost
      user: username
      password: password
      name: database
    ssh: &ssh # SSH anchor
      host: server
      user: foo

staging:
  <<: *default # Reference to the default environment hash, will be merged with sub keys
  vhost: http://staging.foo.com
  database:
    <<: *db # Reference the database hash
    name: db_staging
  ssh:
    <<: *ssh # Reference the ssh hash
    user: foobar

production:
  <<: *default
  vhost: http://www.foo.com
  database:
    <<: *db
    user: bar
    name: db_production

NOTE: the default key is nested under the global because keeping it at first level would make doctor command - and potentially some Wordmove's features - to error. This would happen because every first level key is considered an environment by Wordmove; global is the only right place where to put extra things keeping the doctor green.

Code interpolation

movefile.yml is a YAML file, but it is parsed as an ERB template before being crunched and transformed into an object. This means that you can add dynamic and programmatic behaviors to your config. The language beneath is Ruby, but there are some scenarios where Ruby could be transparent or very easy to use at least.

I'm leaving as example one of the conventions we use in weLaika, in order to easily move a project between different developers.

Everyone in our team has an export in his own shell config:

set --export --global WORDPRESS_WORKS_PATH "$HOME/dev" # Wordmove automagic dev path

This is in fish, but in bash should be something similar to

export WORDPRESS_WORKS_PATH="$HOME/dev"

if I still remember 😉

Now take a look to our movefile.yml:

global:
  sql_adapter: "wpcli"

local:
  vhost: "http://localhost:8080"
  wordpress_path: "<%= ENV['WORDPRESS_WORKS_PATH'] %>/project_name"

Guess what? My wordpress_path will end to be "/Users/fuzzy/dev/project_name".

<% %> are ERB's opening and closing tags. <%= opens a printing tag, so the output will be echoed into the file. ENV is a Ruby Class which acts like a hash-like accessor for environment variables, just like it was an Array.

Easy and convenient, isn't it? Read more about ERB here and more about ENV here

Read more about environment variables and how to conveniently set them within the .env at https://github.com/welaika/wordmove/wiki/Environment-variables

Using local variables with interpolations

You can declare and assign values to arbitrary variables anywhere. In the following example we declare the prod_wp_path at the very beginning of production section in movefile.yml in order to use it both in production.wordpress_path and hooks.pull.after.remote command. Notice that in order to use wp core version command we have to move inside the WordPress root before; this way we DRY up our config.

global:
  sql_adapter: 'wpcli'

local:
  vhost: "http://localhost:8080"
  wordpress_path: "<%= ENV['WORDPRESS_WORKS_PATH'] %>/sshwordmove" # use an absolute path here

  database:
    [...]

production:
  <% prod_wp_path = "/home/sshwordmove/sshwordmove.welaika.com" %>
  vhost: "http://sshwordmove.welaika.com"
  wordpress_path: <%= prod_wp_path %> # use an absolute path here

  database:
    [...]

  exclude:
    [...]

  ssh:
    [...]

  hooks:
    pull:
      after:
        remote:
          - 'cd <%= prod_wp_path %> && wp core version'

Conditionally composing movefile.yml

Using a mixture of the above reported tips it's possible to programmatically enable/disable specific sections of your movefile.yml. E.g.:

  hooks:
    pull:
      after:
        <% if ENV.fetch('FOO', nil) %>
        - where: remote
          command: 'echo "Conditionally run me"'
          raise: true
        <% end %>
        - where: local
          command: 'echo "Always run me"'
          raise false

In ruby ENV.fetch('FOO', nil) means: fetch and return the FOO variable value, fallback to nil if it's not set. ENV.fetch('FOO', false) would have been the same

Obviously you can also check against specific values, not just their precence:

  hooks:
    pull:
      after:
        <% if ENV.fetch('BAR', false) == 'project_1' %>
        - where: remote
          command: 'find -type f -exec chmod 644 {} +'
          raise: true
        <% elsif ENV.fetch('BAR', false) == 'project_2' %>
        - where: remote
          command: 'php bin/my_script.php'
          raise: true
        <% end %>

NOTE: hooks section has been used in the examples, but you can use this approach wherever you need.