Migrating from one un-named node to named nodes¶
Scrutinizer allows you to use different named nodes. This in particular is needed if those nodes run vastly different commands, need different dependencies and so on. Fortunately, it is very easy to migrate to multiple named nodes when needed.
To migrate, simply move the configuration that is currently placed directly under
a named key under
nodes. All the options that you could previously configure, now can be adjusted
for each node separately.
Use Case: Testing Different Sub-Projects¶
If you place different projects in a single repository, let's say a frontend angular application and an API backend, multi environments allow you to set-up different environments for them while still benefiting from our build command inference:
build: nodes: angular: # Assumes that the API project is in a sub-path 'frontend' in your repository root root_path: './frontend' environment: node: v7.4 tests: override: - ng test api: # Assumes that the API project is in a sub-path 'backend' in your repository root root_path: './backend' environment: php: 7.1 tests: override: - vendor/bin/phpunit
Use Case: Testing Different Versions¶
Another use-case for multi-environment builds, is testing against different versions of a language:
build: nodes: php56: environment: php: 5.6 tests: override: - command: vendor/bin/phpunit php71: environment: php: 7.1 tests: override: - command: vendor/bin/phpunit
This configuration will execute each test section with its own settings, each test section will also be run in separate, isolated containers.