Automated Checks

This feature is currently not available for accounts under the free plan. For more details please go to our plans page.

Squash can automatically start new deployments based on each commit and act similar to a Continuous Integration (CI) system. This gives you the power to check if a Squash build is successful and returning a success response for a given commit. You may also automatically run specific commands against the Squash deployment such as running Selenium or Cypress tests (or any other testing tools/frameworks you might be using), allowing you to run your tests on a brand new and fully functional environment.

By default this feature works by starting a new deployment and shutting it down right after Squash receives a success response. However, there are multiple ways to configure this feature to accommodate your specific needs.

The automated checks page

All checks are listed on this page with their own status (building, passed or failed). You may also check the logs for each check and restart them as needed.

How to enable the automated checks for a given repository

To get started just add the auto_deploy_on_commits: true field in the Squash YAML file. Here is an example:

deployments:
  CRM:
    filename:
      ./src/docker-compose.yml
    context_path:
      ./src
    vm_size:
      2GB
    auto_deploy_on_commits:
      true

This will automatically trigger a new check in GitHub/GitLab/Bitbucket for the given application (in the example above the application is called “CRM”). It will look like this in a Pull/Merge Request:

Logs and viewing your app

Click on the “Details” link from the PR check:

If your check is still running you will get a loading page like this, which is a typical Squash deployment. Your application will start working off this page once the build process is finished and a success response is received:

Note the red icon bar at the top-right side of the page. This gives you access to the deployment settings page where you can adjust the expire time of this build and keep it running for a longer period for debugging purposes. You will also find the SSH endpoint info:

Restarting checks

To restart any checks that have already ran, just go to the Checks page and click on one of the historical records:

Then you can either restart from the “Action” dropdown or by clicking on the actual deployment URL:

Customizing the checks’ behavior

auto_deploy_path: use this field to change the default URL path displayed on each check. This is the actual URL Squash will use to check for a success response. For example, you might want Squash to check for a success response within an specific subdomain or URL path like “/app/?pid=1223”.
auto_deploy_ttl: the default time to live of this check. None by default, which means Squash will automatically decommission the deployment once it receives a success response. We recommend using the default settings in order to efficiently use the concurrency and resources in your account.
auto_deploy_disable_cache: this will turn off the Deployment Cache feature for all checks. This is helpful if you need to ensure all these builds are completely build from scratch. Checks may take longer to complete when this field is set to “true”.
auto_deploy_command_success_codes: accepts an additional list of success codes. Squash by default will always accept “0” (zero) as the default success code. This list allows you to add custom success codes for specific scripts.
auto_deploy_post_launch_commands: here you can define multiple scripts to run at the end of the check. You can for instance specify specific tests (Selenium/Cypress/etc) to run against the Squash environment.
build_policy: allows you to control when the checks should run. You can restrict the execution by branches and also control the event handling/triggers by Pull Request or commit to a branch.