When a build starts, Scriptables will connect to your server via SSH using a Golang SSH client.
The builder will then find modules matching the "server type" or "site type" or in the case of servers - you can run more than one module by specifying a comma-separated list of modules in the "Scriptables" input form field.
Modules are a folder of bash scripts found in the scriptables/ folder. This is the actual code that is run on deploys and server builds. The "server type", "site type" or "Scriptables" field values are the module names, lower-cased, and underscored.
Each module has a series of bash scripts named with a prefix "xyz_" - where xyz is a 3-digit number e.g.: 001, 002, 003, and so forth. This prefix controls the order in which the scripts are run - i.e. from the lowest number to the highest number.
Here is a breakdown of the folder structure:
__shared - this is where you should put any code you wish to share with other modules. You can then import this code inside other modules using: SCRIPTABLE::IMPORT modulename .
e.g. scriptables/__shared/auth.sh would be: SCRIPTABLE::IMPORT auth
cache, MySQL, Laravel, lemp,nginx - these are all server and app templates. In the dashboard, if you choose "LEMP" - then the code in the lemp folder will be run to set up your server. The same applies to Nginx, MySQL, and so forth.
_deploy - this is a push to deploy module for your application type. For example, if your application type is "Laravel", on the first build - the module "Laravel" is run to set up and configure the site. After the first build, when you trigger a deployment from either Git webhooks or manually - the builder will look for a folder named "laravel_deploy", which only does the steps needed to update the app such as: pull, migrate, and clear cache.
A typical bash script looks like the following:
#!/bin/bash
# exit-on-failure=yes
cd #USER_DIRECTORY#/#SITE_SLUG#
sudo -u #SITE_SLUG# GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=no -i #KEY_PATH#" git pull
sudo -u www-data php#PHP_VERSION# artisan config:clear
sudo -u www-data php#PHP_VERSION# artisan cache:clear
sudo -u www-data php#PHP_VERSION# artisan view:clear
sudo -u #SITE_SLUG# php#PHP_VERSION# /usr/bin/composer.phar install
sudo -u #SITE_SLUG# php#PHP_VERSION# artisan migrateOn line 2 - exit-on-failure, does just that. When a line fails - the build will just stop at that line and mark the build as a failure.
If this is set to no, the builder will try to continue with the script. If a serious failure occurs, the Script can still exit on failure anywhere, so in most instances it's better to just leave this on.
You will notice variables starting with the hash # symbol e.g. php#PHP_VERSION#. These are automatically replaced on build, by the values you filled in the forms via the interface.
Last updated