The VM Build Process

When you start a new deployment Squash will perform the following steps in this order below. You may also check this quick intro on how Squash works.

Finding a Build plan

• Squash first searches for a Squash YAML file.
• If the file is not present then it checks if there is a deployment profile defined in the Squash Deployment interface.
• If the above fails, then it searches for:
  • ./Dockerfile at the root path of the repository and only if it fails it will look next for the docker-compose file below
  • ./docker-compose.yml at the root path of the repository

Before starting the deployment

Squash will first check if Basic Authentication is set for the repository and enabled for this specific deployment. Then it will also do a user agent check to prevent bots from starting deployments.

• If Basic Auth is enabled, the deployment will only start after the credentials are successfully checked.

Starting the build

Once Squash finds a build plan it will start the build process as follows:

• Start a new clean virtual machine built from scratch.
  • By default all deployments will use the test-instance user account, located at /home/test-instance.

Then there are a few variables that will affect the build process:

When persistent storage is enabled

When the persistent storage is enabled and if there is a persistent volume available to be retrieved. If that succeeds Squash will skip the Deployment Cache below.  Then the build process will continue as follows:

• Attach the /assets/ volume if enabled for the repository. See Assets Storage
• Squash will not pull your latest code from your VCS provider (GitHub, GitLab or Bitbucket).
  • Your code is by default stored under /home/test-instance/code but it will not get updated with the latest code in the branch to avoid destroying any previous data/state. You may define custom deployment actions to help with this step.

When the Deployment Cache is enabled

• Attach a Deployment Cache volume if enabled for the repository, and if available for the given application. This will replace the / mount point with a snapshot from a previous build.
• Attach the /assets/ volume if enabled for the repository. See Assets Storage
• Pull your code from your VCS provider (GitHub, GitLab or Bitbucket).
  • Your code is by default stored under /home/test-instance/code
• NOTE: The build process will be skipped if Squash successfully retrieves a Deployment Cache volume. Squash assumes in this case that the Docker image has been built to speed up the process.

Fresh Build

Here is what will happen when both persistent storage and the deployment cache are turned off, the same happens when you do a “Restart” (not the “Restart with Cache”) from the Squash deployment settings page.

• Attach the /assets/ volume if enabled for the repository. See Assets Storage
• Pull your code from your VCS provider (GitHub, GitLab or Bitbucket).
• Then Squash will run docker build or docker-compose build for the code located at /home/test-instance/code.

After the build process is complete

• Squash will run docker run or docker-compose up. If your application doesn’t use Docker, Squash will still use “docker run” behind the scenes to startup your app.
• Squash will then listen for a success response at the defined HTTP port, until or before ready_wait is reached. Then it will wait/sleep for the entire period defined in backend_wait if it’s been defined in the YAML file.
  • Squash listens to port 80 by default unless defined in the port_forwarding field of the Squash YAML file.
• After receiving a success response Squash will update its routing table and redirect all traffic to the web app running in the deployment, the standard loading page will no longer be displayed.

Using private repositories?

If you are using private repositories please check out some additional resources on Downloading code inside containers and the Squash deploy keys.