Develop Locally: Deploy Scripts
With the advent of the task runner pipeline, a lot of these scripts can be bundled into a single pipeline. The task runner unifies building and deploying code, taking advantage of a wide range of Node build tools – such as Gulp. Therefore, we recommend using the new task runner over these deploy script options.
Deploy scripts can be used to perform setup/cleanup actions when running
Note that the examples below are designed for bash on Mac/*nix systems, but are provided to illustrate the usage of these scripts. The logic here can be translated into the scripting or programming language of your choice. You may set the pre- and post-deploy scripts to be the same executable if you want to consolidate your logic.
How to Pass Arguments
The most basic way to call a pre- or post-deploy script is to simply pass a path to the executable, such as
moov deploy --pre-deploy=./executable myaccount/myproject
In order to pass flags or command line arguments to the deploy script, you can run the
moov deploy command as follows:
moov deploy --pre-deploy="./executable -flag1 -flag2" myaccount/myproject
For example, suppose a local project’s code is managed by Git, we could set our pre-deploy script to abort the deploy if the project directory has pending changes, but allow the user the option to force the deploy if they want. We can add the following code into our pre-deploy shell script:
# ... # assume prior to this, if the -f flag is passed, $FORCE is set to "true" # also assume the revision control being used is git if [ -z "`git status | grep 'nothing to commit'`" ]; then # check to see if the repo is clean if [ $FORCE = "true" ]; then echo "The deploy is being forced, ctrl+c to cancel if this is a mistake." 1>&2 sleep 2 # give some chance to stop a possibly incorrect deploy echo "Continuing..." 1>&2 MOOV_DEPLOY_NOTES="$MOOV_DEPLOY_NOTES -- The directory was unclean and forced to deploy." FORCED="true" # condition on the forced-ness later maybe else echo "Directory isn't fully clean, either fix that or rerun the script with the -f option if it's all good to go." 1>&2 echo "Note that forcing the deploy may, in fact, ruin your repo's state. Use the force flag with caution." 1>&2 exit 1 # Exit status of non-zero halts deployment. fi else MOOV_DEPLOY_NOTES="$MOOV_DEPLOY_NOTES -- Push of a clean directory." fi # … continue the script
We then call
moov deploy as follows:
moov deploy --pre-deploy="./myexecutable -f" myaccount/myproject
In this case, the
-f option is passed to the myexecutable script.
This example code illustrates a few properties of the deploy scripts which we’ll cover below.
Use of stderr
In order to print messages to the terminal, you must print to stderr. Messages printed to stdout will be consumed by the deploy command and will not appear in the terminal unless the
-verbose flag is set on the
moov deploy command. For bash scripts, you can redirect the output for echo statements to stderr using
1>&2 at the end of the bash statement.
How to Abort a Deploy
In the above code, in case of an error, the script exits with status code 1. When a pre-deploy script exits with a non-zero return status, it signals the deploy command to abort deploying to the Control Center. You can also abort a deploy by issuing a Ctrl+C while the pre-deploy script is executing. In both of these cases, the
moov deploy will abort, and the post-deploy script will not be run.
Deploy Script Variables
The parameters of the
moov deploy command are made available to the deploy scripts via environment variables. Any of the options or command line arguments for
moov deploy will be placed in these environment variables for the deploy scripts to consume. These can then be used by the deploy scripts to invoke certain logic or to make decisions based on those parameters. You can change some of these values by printing the variable name, followed by an equals sign, followed by the new variable value to stdout. That is, you print “
<variable_name>=<variable_value>” to stdout. For example, you can use this to add to the notes or change them entirely; change the mode, layer, account, etc.; generate the deployment identifier on the fly; and more. The following code snippet lists all the predefined variables and gives an example of how to change them.
#!/bin/bash # example script, which shows all the variables and how to mutate them # Print out the values echo $MOOV_DEPLOY_ACCOUNT_NAME >&2 echo $MOOV_DEPLOY_SITE_NAME >&2 echo $MOOV_DEPLOY_MODE >&2 echo $MOOV_DEPLOY_PROJECT_DIR >&2 echo $MOOV_DEPLOY_LAYER >&2 echo $MOOV_DEPLOY_DEPLOYMENT_ID >&2 echo $MOOV_DEPLOY_PRE_DEPLOY >&2 # mutating doesn't affect anything, provided to allow tailored notes echo $MOOV_DEPLOY_POST_DEPLOY >&2 # The cleanup script to run, should just be used to append the appropriate flags to clean up correctly and/or make tailored notes echo $MOOV_DEPLOY_NOTES >&2 # post deploy exclusives echo $MOOV_DEPLOY_MODE_VERSION >&2 # only valid in the post-deploy echo $MOOV_DEPLOY_STATUS >&2 # only valid in the post-deploy # Inform the user of the changes we're about to make... echo "Overriding these:" >&2 echo " site: demosite" >&2 echo " mode: demomode" >&2 echo " layer: demolayer" >&2 echo " deployment id: some_git_hash" >&2 echo " notes: these are the deployment notes" >&2 # and how to make those changes... echo MOOV_DEPLOY_SITE_NAME="demosite" echo MOOV_DEPLOY_MODE="demomode" echo MOOV_DEPLOY_LAYER="demolayer" echo MOOV_DEPLOY_DEPLOYMENT_ID="some_git_hash" echo MOOV_DEPLOY_NOTES="these are the deployment notes"
The following two variables are not set by command line arguments or other user input, but rather by the Moov build/deploy system.
$MOOV_DEPLOY_MODE_VERSION is the build version number found in the Control Center for the particular deploy that was executed (usually ‘v’ followed by a number, e.g. v15). As an example, you might use this value to tag a branch of your project code in your source version manager in order to facilitate debugging and tracking your changes.
$MOOV_DEPLOY_STATUS is a string that is set to either
"failure". This status is set based on whether building and deploying your project to the Control Center was successful. As an example, you might use this value to perform cleanup or logging, based on whether or not the deploy was successful. Another example would be adding a description to the tag of whether the build was successful or not so that a user doesn’t need to open up the Control Center to check.