👨‍💻Under the hood

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:

1. __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

2. 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.

3. _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 migrate

On 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.