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