Build Config Reference

Below, you find a reference for the entire build section. We recommend to only copy parts you need in your configuration, and otherwise use our defaults:

build: nodes: # Sets up multi-environment builds, see https://scrutinizer-ci.com/docs/build/multiple_test_environment my-first-test: # ... All other options under "build" except "nodes" my-second-test: requires: # will only run when my-first-test passes - node: my-first-test # will only run when build is related to the "master" branch - branch: master # or you can also use a regular expression to match multiple branches - branch: /master|staging/ # will only run when no failure conditions were met in the analysis - analysis # ... All other options under "build" except "nodes" # Defines the root path for your project, defaulting to the repository root directory. root_path: './' # Allows you to allocate more CPU bandwidth to your build environment if your tests # benefit from running on multiple CPU threads. The number of CPUs is limited by the # number of containers in your subscription. resources: cpus: 1 environment: # Any valid timezone identifier # see TZ column on https://en.wikipedia.org/wiki/List_of_tz_database_time_zones timezone: UTC # Sets up DNS entries for certain hosts hosts: local.dev: 127.0.0.1 another-domain.dev: 127.0.0.1 # Any environment variables we should set for you. variables: FOO: bar ANOTHER_VAR: baz # APT packages that should be installed via apt-get install in the environment. apt_packages: - my-package1 - my-package2 # Your heroku credentials for deployment if needed. # Recommended to be kept on the website only. heroku: email: my@email api_key: heroku-api-key # Your aws credentials for the aws CLI used for deployment or other tasks. # Recommended to be kept on the website only. aws: key: aws-key-here secret: aws-secret-here # Languages php: version: "7.0" # Run "php -i | grep -i configure" in the build container for defaults compile_options: '--enable-sigchild' # Install additional extensions from https://pecl.php.net pecl_extensions: - redis - memcached ini: memory_limit: "-1" python: version: "3.5.0" # Whether to setup a virtualenv in the repository root directory. virtualenv: true java: "java-8-oracle" ruby: "2.3.1" node: "v6.2.0" go: "go1.6.2" docker: logins: - { username: "user", password: "s3cret", server: "docker.io" } - # more logins remote_engine: enabled: false # By default, the disk is 20G of the remote engine. If you need # more than that, you can gain an additional 5GB for each additional # CPU you have requested for the container (see resources above). grow_disk: false apache2: modules: [] sites: my-site-name: host: local.dev # also make sure to add under "hosts" above web_root: web/ rules: - RewriteRule # ... - AnotherEntry # will be added to the <VirtualHost> entry of this site nginx: sites: # will add configuration file to "/etc/nginx/sites-enabled" my-site-name: host: 'local.dev' web_root: 'web/' # These are optional and usually do not require changing. index: 'index.php index.html' 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; } selenium: browser_name: ~ # can also be set from your tests # Legacy services, use service containers for more flexibility/speed (see below) mysql: 5.5 postgresql: true redis: true elasticsearch: "2" rabbitmq: false mongodb: false neo4j: false memcached: false # Standalone Service Containers # # You can run any Docker image as a service. Services are started at the beginning of your # build and linked into your main container. The images are also cacheable between builds # reducing start-up times. # # Services are not run inside your main container, but external to it. As a result, you # cannot see them when running "docker ps" in your build container. services: # Short Notation: # # For some services, we offer a short notation where you only need to pass the chosen # Docker tag. You can find out which tags are available at # https://hub.docker.com/_/SERVICE_NAME/ # # If not listed here, you can always use the long notation (see below). mysql: 5.7 mariadb: 10 postgres: 10 rabbitmq: 3-management redis: 4 mongo: 4 elasticsearch: 6.4.2 neo4j: 3.4 # Long Notation: some-name: image: docker.io/library/something:123 # Define any additional environment variables that are needed by the service. env: SOME_ENV_VAR: ENV_VAR_VALUE # We automatically forward these ports from your localhost to the service's port. # Alternatively, you can also access the service on the "$SERVICE_SOME_NAME_IP" # environment variable. ports: # Forward 127.0.0.1:12345 -> SERVICE_IP:12345 - 12345 # Forward 127.0.0.1:4000 -> SERVICE_IP:3306 - service_port: 3306 local_port: 4000 # If your service writes data to disk like most databases do, you can significantly # speed up tests by mounting a ramdisk at those paths. ramdisks: - /var/lib/data ## ## Minimal Nodes Options ## commands: - simple-command-string # or full command hash - command: some-command cwd: . # How long in seconds we should wait for the command to produce some output before # we consider it broken and terminate it. idle_timeout: 180 environment: SOME_KEY: VALUE ANOTHER_KEY: VALUE # The title is displayed in the UI. It defaults to the command itself, but you can # overwrite it if your command is very long and not very descriptive. title: "Compile ABC" # If true, this command will be run in the background. background: false # A node number, when you want to run builds in parallel. You can configure any number here. # All commands with the same number will be run in the same container. Commands with no # explicit number configured will run in all containers. on_node: ~ # 1, 2, 3, and so on # If you run browser based tests. You can have Scrutinizer record a video of the # display so that you can more easily debug any errors that occur. The video is # done in a low overhead format and only re-encoded when your tests actually fail. # Should your tests pass, the video is discarded. record_video: false # Helpers to execute a command conditionally, accepts any command valid command. # Useful if you want to cache an expensive compilation for example. only_if: "test -e command-is-only-executed-if-this-path-exists" not_if: ~ # Optional. If the command produces a coverage file, you can let the platform know where and # what format it has, so we can correctly process it and show you the results. # See dedicated code coverage section for details. coverage: file: ~ config_file: ~ format: ~ # Optional. If the command produces analysis results, sometimes it's necessary to explicit # configure the result file and its format. See dedicated open-source tools # section for details. analysis: file: ~ format: ~ ## ## Auto-Setup Nodes Options ## cache: disabled: false # Accepts an array of directories directories: - ~/relative-to-the-users-home - ~/.m2 - or-relative-to-your-project - vendor/ # Used for installing any needed dependencies by your project like apt package or libraries. dependencies: # Commands that should be run before the inferred commands in the dependencies section before: - simple-command # or a command hash - command: some-command # ..., see Minimal Nodes Options above for all options of this hash. # Commands that should be run instead of the inferred commands in the dependencies section. override: # Same format as above in "before". # If you want to override the inferred commands, you can move your entire "before" # and "after" commands into the "override" section. If you do not have any commands # in those sections, you can also just add "true" as command which is bash built-in. # Commands that should be run after the inferred commands in the dependencies section. after: # Same format as above in "after". # Useful if you want to keep the inferred commands, and just add something # after they have run. # Follows the same structure like the dependencies section. # Used for project setup like configuring the database, preparing the schema, importing fixtures, etc. project_setup: before: [] override: [] after: [] # Follows the same structure like the dependencies section. # Used for running your tests and open-source analysis tools. # We will execute all commands even if one of them fails. tests: # If true, tests execution will stop by any command failure. stop_on_failure: true before: - command: stop_on_failure: true # If true, tests execution will stop when this command failed. override: [] after: [] # Used for deployment. # Will only be executed if all tests succeeded. # If run in parallel, will be executed in the container where tests finish last. deployment: - # Optional. If this should only be executed for pushes to a certain branch. branch: master # The branch name is exactly "master"            branch: '/^feature/' # Any branch name that starts with "feature" commands: - aws s3 cp my-file s3://my-bucket/my-file - git push heroku master - or-any-other-command