Continuous Integration

Deployment

Deployment is just another node in your build that has certain requirements, giving you great flexibility to adapt it to your workflow.

•       Great flexibility how and when deployment is done
•       Comprehensive requirements like other nodes, certain analysis conditions or branch requirements can be used

    
build:
    nodes:
        tests-1:
            # ...
        tests-2:
            # ...
        analysis:
            # ...
        deploy:
            requires:
                - node: tests-1   # tests-1 passed
                - node: tests-2   # tests-2 passed
                - analysis        # no failure conditions met
                - branch: master  # only for master branch
        commands:
            # Deploy by git push
            - checkout-code ~/code
            - cd ~/code
            - git push some-remote master
        # package code
            - checkout-code ~/code
            - (cd code && restore-from-cache execution assets)
            - tar -czf code.tar.gz code/
            - # move code.tar.gz somewhere
        # or any other command
    

Webserver Setup

Scrutinizer can automatically configure a range of services for you. For example, configuring NGINX can involve complicated path configuration and starting of background tasks such as php-fpm. Scrutinizer can take care of this for you.

•       Simple configuration-based set-up of services.
•       No need to spend time on complex path configurations, starting of background processes or capturing log information for debugging.

    
build:
  environment:
    nginx:
       sites:
         symfony_app:
           host: 'local.dev'
           web_root: 'web/'

           # These are optional and
           # usually do not require changing.
           index: 'index.php index.html'

           # By default Scrutinizer will
           # generate the following location
           # block for the configuration file.
           # But you can simply overwrite
           # it with your own location blocks
           # by adding them under ``locations``

           locations:
               - >
                  location ~ [^/]\.php(/|$) {
                    try_files $uri $uri/ /index.php /index.html;
                    fastcgi_index index.php;
                    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
                    fastcgi_pass 127.0.0.1:9000;
                    include fastcgi_params;
                  }
    

Caching

Scrutinizer allows you to directly interact with the cache via regular shell commands.

Since you directly interact via shell commands you can take advantage of powerful UNIX features such as piping data from and to the cache.

•       Cache interaction via regular shell commands
•       Pipe data from other shell commands like tar or docker
•       Fine-grained caches with keys you can choose

    
build:
  nodes:
    # In this example, we are using a minimal node.
    some-node:
      commands:
        # Store folder vendor/ with key "dependencies".
        # This means all nodes use the same
        # cache for dependencies across all branches.
        - store-in-cache repository "dependencies" vendor/
        - restore-from-cache repository "dependencies"
        - exists-in-cache repository "dependencies"

        # If you would like to use a different
        # cache per branch, you can make the branch
        # name part of the cache key like this.
        - >
          store-in-cache repository
          "dependencies-$SCRUTINIZER_BRANCH" vendor/
        - >
          restore-from-cache repository
          "dependencies-$SCRUTINIZER_BRANCH"
        - >
          exists-in-cache repository
          "dependencies-$SCRUTINIZER_BRANCH"

        # If you further would like to use a
        # different cache per branch and per node, all
        # we need to do is to add the node name to the cache key, too.
        - >
          store-in-cache repository
          "dependencies-$SCRUTINIZER_BRANCH-$SCRUTINIZER_NODE_NAME" vendor/
        - >
          restore-from-cache repository
          "dependencies-$SCRUTINIZER_BRANCH-$SCRUTINIZER_NODE_NAME"
        - >
          exists-in-cache repository
          "dependencies-$SCRUTINIZER_BRANCH-$SCRUTINIZER_NODE_NAME"

        # The storing command is a regular system command, so you can use any environment
        # variables or the output of other commands to make up the cache key. For example,
        # if you wanted to automatically invalidate the cache if a certain file like a lock file
        # changes, this could look like this:
        - >
          store-in-cache repository
          "dependencies-$(sha1sum some.lock | awk '{print $1}')" vendor/
        - >
          restore-from-cache repository
          "dependencies-$(sha1sum some.lock | awk '{print $1}')"
        - >
          exists-in-cache repository
          "dependencies-$(sha1sum some.lock | awk '{print $1}')"
    

Docker

Scrutinizer fully supports Docker including building your own Docker images and Docker layer caching.

•       Unrestricted syscalls for building images via the remote engine
•       Easy setup of Docker via the configuration
•       Cache compute-intensive layers to speed up subsequent builds

    
build:
  nodes:
    buildImage:
      environment:
        docker:
          # For unrestricted syscalls
          remote_engine: true

        # Push images or pull private images from a registry
        # Simply define logins in the configuration:
        logins:
           # DockerHub
           - { username: "my-user", password: "my-password" }
           - { username: "another-user", password: "some-pass", server: "quay.io" }

      commands:
        - command: >
            restore-from-cache repository layers -
            | docker load
          only_if: exists-in-cache repository layers

        # ... your other commands

        - >
          docker save SOME_LAYER
          | store-in-cache repository layers -