Skip to content

Post-deployment scripts

Only for PHP

Currently this option available only for PHP stacks


Wodby provides you a way to run your scripts after each deployment. You can defined post-deployment scripts in wodby.yml file via pipelines (example for command stage):

  - name: Drupal 8 clear cache on dev
    type: command
    command: drush cr
    directory: $HTTP_ROOT
    only_if: test "$WODBY_ENVIRONMENT_TYPE" = "dev" 

Root directory

In the example above $HTTP_ROOT used as a directory instead of $APP_ROOT because drupal root is in a subdirectory (composer-based project)

Or like this:

  - name: Run my custom script
    type: command
    command: ./
    directory: $APP_ROOT

The pipeline is an automated manifestation of your deployment process. In other words, it's just a set of post-deployment actions to execute

Available environment variables

See Environment Variables article.

Cleanup pipeline

wodby.yml can have one cleanup block; cleanup is another pipeline which needs to be executed after a pipeline has either failed or passed. In the cleanup block, we can add command or shell script stages. The below example create a log file in pipeline and then cleanup the log file in the cleaup steps.

  - name: start pipeline
    command: echo “pipeline” > log/log.txt
  - name: cleanup
    command:  rm log/*

Pipeline stages

Stage in pipeline has three elements, name, type and configurations. configuration elements are optional. The elements of configurations depend on the type. For example command_stage type has command configuration, which specify the shell command run in the stage. The following is the table on the type and the parameters.

Command stage

Command stage executes one command. Users specify Command stage adding command in type.

The following is the parameter of Command stage.

Configuration Optional meaning
command false shell command run in the stage
only_if true run specified command on when the condition written in only_if is satisfied
directory true the directory where wodby runs the specified command

Parallel stages

You can set child stages and run these stages in parallel like this.

  - name: parallel stages
      - name: parallel command 1
        type: command
        command: parallel command 1
      - name: parallel command 2
        type: command
        command: parallel command 2
      - name: parallel command 3
        type: command
        command: parallel command 3

In the above setting, parallel command 1, parallel command 2 and parallel command 3 are executed in parallel.

Reusing the results from stages

Wodby stores the results of preceding stages. The stages can make use of the results of finished stages using the three special variables (__OUT, __ERR, __COMBINED and __RESULT) in wodby.yml configuration files.

  • __OUT - output flushed to standard output
  • __ERR - output flushed to standard error
  • __COMBINED - combined output of stdout and stderr
  • __RESULT - execution result (true or false)

The three variables are maps whose keys are stage names and the value are results of the stages. For example, we want the standard output result of the stage named "stage1", we write __OUT["stage1"].

The following is a sample configuration with a special value.

  - name: stage_1
    command: echo "hello world"
  - name: stage_2
    command: echo __OUT["stage_1"]

Wodby with the above configuration outputs "hello world" twice, since the second stage (stage_2) flushes the standard output result of the first stage (stage_1).

Wait for running stages until the conditions are satisfied

The stage starts immediately after the previous stage finish, but some stages need to wait for some action such as port is ready or file are created. wait_for feature supports the actions which need to be ready before the stages begin.

wait_for is defined as a property of stage.

  - name: launch solr
    command: bin/solr start
  - name: post data to solr index
    command: bin/post -d ~/tmp/foobar.js
    wait_for: host=localhost port=8983 state=ready

The wait_for property takes the key value pairs. Key has several variations. The value depends on the key type. The following table shows the supported key value pairs and the description.

Key Value (value type) Description
delay second (float) Seconds to wait after the previous stage finish
port port number (int) Port number
file file name (string) File to be created in the previous stages
host host (string) IP address or host name
state state of the other key (string) Four types of states are supported. The possible value is dependent to the other Keys.

State values

There are several state values and possible state values are depend on the other key.

There are seveal state values and possible state values are depend on the other key.

State value Description
present / ready Specified port is ready or file is created.
absent / unready port is not active or file does not exist

Creating your own pipeline stage

You can create your own pipeline stage and then use them in your pipeline.

The the example below where we define two simple pipelines hello and goodbye.

namespace: mypackage

  - def:
      name: hello
      command: echo "May I help you majesty!"
  - def:
      name: goodbye
      command: echo "Goobye majesty."

To import stages to pipeline configuration file, we use require block and add the list of file names into the block.

For example, the following example import the stages defined in conf/mystage.yml

    - conf/mystages.yml

  - call: mypackage::hello
  - call: mypackage::goodbye

In the above setting, the stages (mypackage::hello and mypackage::goodbye) which are defined in mystage.yml are specified.

The files specified in pipeline configuration file need to have two blocks namespace and stages. In namespace, we add the package name, the package name is need to avoid collisions of the stage names in multiple required files. The stages block contains the list of stage definitions. We can define the stages same as the stages in pipeline configurations.

Initializing git submodules

  - name: Ignore SSH host key check for github and bitbucket
    type: command
    command: 'printf "Host\n\tStrictHostKeyChecking no\n" >> ~/.ssh/config'

  - name: Git sub-modules setup
    type: command
    command: git submodule update --init --checkout
    directory: $WODBY_APP_ROOT


You can find output logs of executed post-deployment scripts under Instance > Tasks