backend_wait

• Defines the waiting period (in seconds) after receiving an HTTP response from a successful deployment before the routing to the VM’s application is established. This is helpful for some containers where the application’s backend might need more time to startup after the web server has already started.
• Mandatory field: No
• Data Type: Integer
• Default value: 0

build_policy

• This field works with the Automated Checks feature and allows controlling when the automated checks should run. By default the checks will run for all branches and will be triggered by pushing new commits or by creating a new Pull Request (GitHub/Bitbucket/GitLab).
• Mandatory field: No
• Data Type: dict
• Default value: null

Options available for this field:

• triggers: accepts either “pr”, “commit” or both options, comma separated.
  • pr: this will trigger a new check execution when a new Pull Request is created (GitHub/Bitbucket/GitLab).
    • You may also restrict the destination branch of the Pull Request as follows:
      • pr[master]
      • For this example above the Automated check will only run when the destination branch of the PR is branch “master”
    • You may also use multiple branches separated by semicolon (;):
      • pr[branchA;branchB;branchC]
  • commit: starts a new check by pushing a new commit to a branch.
  • Default value: pr, commit
• restrict_branches: comma separated list of branches that will not trigger automated checks.
  • Default value: null
  • No branches are restricted by default.
• allow_branches: comma separated list of branches that will accept the automated checks. The asterisk (*) value is also accepted to indicate all branches are accepted.
  • Default value: *
  • All branches are accepted by default.
• auto_cancel: when new commits are pushed to a given branch, any existing automated checks that might be running will be automatically canceled.
  • Available choices: true, false
  • Default value: false
• wait_time: this allows Squash to wait for a pre-defined amount of time before starting the automated check execution. This is useful for branches receiving commits very often and helps to reduce multiple concurrent checks for the same branch. When a developer pushes a new commit Squash will wait for a given amount of time, if new commits are pushed to that same branch and within the wait time then squash will only execute the check for the last commit after the wait time has expired.
  • Default value: null. By default Squash always executes a new automated check for each commit.
  • Available choices (“m” = minutes, “h” = hours): 5m, 15m, 30m, 1h, 2h, 3h, 4h, 5h, 6h

Squash YAML file sample:

deployments:
  MyApp:
    filename:
      ./Dockerfile
     build_policy:
      # available options: pr, commit. Default value is
      # "pr, commit", either a new PR or commit will
      # start a new build
      triggers: pr 
      # by default this is empty -
      # no restrictions
      restrict_branches: branchA, branchB 
      # default value is "*" which means all branches
      allow_branches: staging, production

copy_files

• Defines files that should be copied, specified in <source> <destination> format.
• Mandatory field: No
• Data Type: List
• Default value: null

Example:

deployments:
  MyApp:
    filename:
      ./src/Dockerfile
    copy_files:
      - /assets/photos/ ~/code/myapp/photos/
      - /assets/product-pictures/ ~/code/myapp/product-pictures/

copy_files_build_process

• Defines files that should be copied only before build process, specified in <source> <destination>format. This step is skipped when either Deployment Cache or Persistent Storage are being used.
• Mandatory field: No
• Data Type: List
• Default value: null

Example:

deployments:
  MyApp:
    filename:
      ./src/Dockerfile
    copy_files_build_process:
      - /assets/dev-db.zip ~/code/myapp/dev-db.zip
      - /code/config/.profile ~/.profile

check_service_ports

Used by non-HTTP based deployments only. When this field is defined for a given application Squash will no longer check for HTTP success responses. Instead, Squash will ping one or more port numbers defined in this field in order to detect if the deployment is up.

By default, Squash will automatically open in the firewall all ports specified in this field, for the private IP only. You can customize this behavior by using the allow_traffic_ports field.

• Defines one or more comma separated port numbers. These are port numbers of one or more services you might be running within this specific deployment.
• Mandatory field: No
• Data Type: Integer, comma separated
• Default value: null

Example:

deployments:
  DatabaseService:
    dockerimage: postgres:9.4
    run_options: -e POSTGRES_PASSWORD=passwd -e POSTGRES_USER=user
    check_service_ports: 5432
    port_forwarding: 5432:5432

In this example above we are deploying a PostgreSQL database, named “DatabaseService” based on a given Docker image. For more information please check the non-HTTP based deployments page.

default_pr_comment

• See: customizing PR comments.
• Display the root endpoint URL without any query strings or subdomains
• Mandatory field: No
• Data Type: Boolean
• Default value: True

The default PR comment looks like this and it’s included by default for every application within the Squash YAML file:

depends_on

This will enable the Deployment Dependencies feature.

• Defines one or more dependencies. Dependency items can trigger separate Squash deployments.
• Mandatory field: No
• Data Type: list of dictionaries. The format for each dict item is
  • <ENV_VARIABLE_NAME>: app: <repository_name>/<branch_name>/<AppName>
  • both “branch_name” and “app_name” are optional.
  • “app_name” is only needed when multiple apps are defined in the Squash YAML file. Note: when app_name is not specified, Squash will automatically use the first application defined in the YAML file.
  • Optional field: subdomain, this is only needed when mapping specific services within the same VM.
  • You may also define a custom default branch as follows:
    • my-repo/[dev]
    • In the example above Squash will use the branch named “dev” instead of the current default branch set in GitHub/Bitbucket/Gitlab. This is always used as a fallback in case Squash can’t find a branch with the same name as in the parent repo (see examples below).
• Default value: null

Example using one single dependency. PRODUCTS_API is the actual environment variable name that will be set in the CRM app deployment with the endpoint of this dependency as the env variable value. “api-products” is a repository name. Because we are not specifying any branch names Squash will attempt to use a branch names that matches the same branch name in the parent, otherwise it will fall back to the default branch (usually master) in the “api-products” repo.

deployments:
  CRM:
    filename:
      ./src/Dockerfile
    depends_on:
      - PRODUCTS_API:
          app: api-products

Three dependencies:

• The first dependency only accepts branch “master” within the api-products repository.
• The 2nd dependency requires an exact application within the api-search repository. Since we are not defining a specific branch name Squash will look for the exact same branch name as defined in the parent. If a matching branch name doesn’t exist on repository “api-search” then squash will use the default branch in the repo (most of the times it will be branch “master”).
• The 3rd dependency requires branch “master” and the exact application named “App1”.

deployments:
  CRM:
    filename:
      ./src/Dockerfile
    depends_on:
      - PRODUCTS_API:
          app: api-products/master
      - SEARCH_API:
          app: api-search:App2
      - ENTITIES_API:
          app: api-entities/master:App1

Example using a custom default branch as a fallback:

MyWebApp:
   filename:
     ./src/Dockerfile
   depends_on:
     - PRODUCTS_API:
         app: products-repo/[dev]

Because we are not specifying any branch names Squash will attempt to use a branch name that matches the same branch name in the parent (the repo that hosts the actual file above for MyWebApp), otherwise it will fall back to the custom default branch “dev” in the “products-repo” repository.

More information on using dependencies with Squash.

deployment_page_commands

• See: Custom Deployment Actions.
• Defines additional commands that might be executed for a running deployment from the Squash Dashboard page.
• Mandatory field: No
• Data Type: Dictionary
• Default value: null

Field structure:

deployment_page_commands:
  <command name to be displayed>:
    - <scripts to be executed for all containers>
  <command name to be displayed>:
    <target container name>:
      - <scripts to be executed for a specified container>
  <command name to be displayed>:
    # "squash_host" is a reserved word to indicate that
    # the commands below will run in the host VM
    squash_host:
      - <scripts to be executed within the host VM>

.squash.yml sample:

deployments:
  MyApp:
    filename:
      ./src/Dockerfile
    deployment_page_commands:
      Restart services:
        - /home/deploy/myapp/restart.sh          
      Run cronjob:
        cronjob-container-name:
          - /home/deploy/myapp/run-cronjob.sh             
      Update App:
        squash_host:
          - /home/test-instance/code/update_app.sh

domain

• See: Custom Domains & Custom SSL.
• A custom domain such as example.com. Please note that you need to contact our support in order to enable custom domains in your account.
• Mandatory field: No
• Data Type: String
• Default value: null

.squash.yml sample:

deployments:
  MyAppName:
        filename:
          ./myapp/Dockerfile
        domain:
          example.com

environment

• See: Environment Variables.
• List of environment variables that applies to a single application.
• Mandatory field: No
• Data Type: List of key: value pairs
• Default value: null

Example:

deployments:
  CRM:
    filename:
      ./src/Dockerfile
    environment:
      - TEST_VAL=42
      - CLIENT_API_ID=7612

deployments:
  MyApp:
    filename:
      ./src/Dockerfile
    environment:
      - CLIENT_API_KEY=$API_KEY

deployments:
  MyApp:
    install:
      - kubectl label namespace default istio-injection=enabled
      - kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
      - kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
      - export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
      - export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
      - export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].port}')
      - export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
      - kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml
      - kubectl create ns foo
      - kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
      - kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo

deployments:
  MyApp:
    install:
      - docker-compose build
      - docker-compose up -d
      - docker-compose exec app bash -c 'python manage.py makemigrations && python manage.py migrate'

deployments:
  CRM:
    filename:
      ./src/crm/Dockerfile
    context_path:
      ./src
    post_launch:
      - target: app
        command: exec
        options: "{target} bash -c 'python manage.py makemigrations && python manage.py migrate'"

deployments:
  MyApp:
    filename:
      ./src/Dockerfile
    context_path:
      ./src
    post_launch:
      - target: app
        command: exec
        options: "{target} bash -c 'python manage.py makemigrations"
      - target: app
        command: exec
        options: "{target} bash -c 'python manage.py migrate'"

deployments:
  MyApp:
    filename:
      ./src/Dockerfile
    post_launch:
      - context: squash_host
        command: /home/test-instance/code/update_app.sh

deployments:
  MyApp:
    filename:
      ./src/Dockerfile
    post_launch:
      - context: squash_host
        command: squash-docker-compose -f /home/test-instance/code/docker-compose.yml run myapp ./script.sh

MyWebApp:
   filename:
     ./src/Dockerfile
   pr_comment_check_folders:
     - src/
     - templates/

deployments:
  MyAppName:
        filename:
          ./myapp/Dockerfile
        pre_terminate:
          - ./src/scripts/script-1.sh
          - ./src/scripts/script-2.py

You may also specify commands that will only run for certain containers. In this case use the container name to group the scripts you want to run. Example:

pre_terminate:
  - container-nameABC:
      - ./src/scripts/script-1.sh
      - ./src/scripts/script-2.sh
  - container-nameXYZ:
      - ./src/scripts/script-3.sh

deployments:
  CRM:
    filename:
      ./src/crm/Dockerfile
    context_path:
      ./src
    vm_size:
      1GB
    run_options: --hostname ${SQUASH_BRANCH_WITH_ID} --env SQUASH_BRANCH=${SQUASH_BRANCH}

subdomains

See: Customizing PR Comments.

This is where you can list multiple pre-defined subdomains to appear in a Squash PR comment. Note that this only affects the display on PR comments, you can still use any subdomains with any deployments by manually adding a double dash (--) in a deployment URL.

Example yml file:

deployments:
  AppName1:
        filename:
          ./src/module1/DockerfileABC
        default_pr_comment:
          False
        subdomains:
          Customers:
                 - drugstore
                 - bookstore

PR comment output:

You may also specify pre-made URL paths and arguments that will be used by default in the PR URLs. For example, if you want some deployment links to use the path /login/ you can do so by adding a comma after the subdomain name and adding the desired URL path afterwards. This is how it looks like in the .squash.yml file:

subdomains:
  Customers:
         - bookstore,/login/
         - drugstore,/login/?uid=1234

And Squash will display the automatic PR comment as follows:

https://bookstore--cartv2-zh1cw.squash.io/login/

and

https://drugstore--cartv2-zh1cw.squash.io/login/?uid=1234

• Mandatory field: No
• Data Type: List of subdomains in text format
• Default value: null

subdomain_port_mapping

• See: Subdomain port mapping.
• Use this option to assign a subdomain to an specific port associated to a docker container/service. This is useful when you are deploying micro services using docker-compose, with multiple containers within the same deployment.
• Format for this field: <subdomain>:<port>.
• Only one port mapping per subdomain is allowed.
• Mandatory field: No
• Data Type: List of strings
• Default value: null

Example:

deployments:
  MyAppName:
    filename:
      ./myapp/docker-compose.yml
    subdomain_port_mapping:
      - api:8080

success_response_check

Defines custom logic for the success response check before Squash routes the deployment.

By default squash will first check for a success response on the original URL that triggered the deployment, then it will check for URLs (if any) defined within the “subdomains” field in the Squash YAML file. This default logic can be overwritten by using this “success_response_check” field allowing developers to fully customize what URLs to check before the deployment is routed.

This field expects a list of fields according to this basic structure:

success_response_check:
  fallback: true/false # default is "true" 
  url_check_behaviour: first_success/check_all # default is "first_success"
  urls: # one ore more URLs are expected
      - <URL 1>
      - <URL 2>

vm_size

This is the VM size to use for a given deployment. By default Squash will use the repository VM Size as defined in Settings -> Repositories.

You may override this on a per branch basis by using the vm_size option in the .squash.yml file.

Available choices:

• 1GB
• 2GB
• 4GB
• 8GB
• 16GB

See our pricing page for more information on the specs of each VM.

• Mandatory field: No
• Data Type: List of VM sizes in text format
• Default value: null