Each build on Scrutinizer consists of one or more nodes. Each node is either an auto-setup node or a minimal node. You can mix these types in the same build as needed.
On auto-setup nodes, Scrutinizer will infer certain commands based on the structure of your project. This can be things like the version of languages, dependency installation commands to run, or also which tests to execute. This is very helpful as you get started on Scrutinizer as often all you need to do is just add a project and everything will just work automatically.
On auto-setup nodes, commands are split into three different sections:
build: nodes: some-name: dependencies: before: # runs before inferred commands - some-command - other-command override: # overrides inferred commands # ... after: # runs after inferred commands # ... project_setup: # ... tests: # ... cache: directories: - a - b
For each section, you can decide whether you would like to run additional commands before or after the automatically inferred commands or also to override the inferred commands entirely.
On auto-setup nodes, the code is always checked out at the very beginning to the ~/build directory in your home folder. Likewise, the cache is restored once at the beginning and stored again at the end of a build. You can configure which directories are to be cached and Scrutinizer will also automatically add directories used by common package managers.
The cache is always scoped by node and branch. So, different nodes and different branches have separate caches.
On minimal nodes, Scrutinizer will not infer any commands, but just start the container, inject environment variables and some access credentials like SSH keys.
On minimal nodes, all commands are placed in a single section; there are no automatically added commands:
build: nodes: some-name: commands: - some-command - other-command
You have full control over which commands and the order of commands that is run.
On minimal nodes, you have full control over when and where code is checked out and you can also decide when your cache is restored, or when and which directories are stored in the cache.
Scrutinizer provides some commands to make this still very easy:
build: nodes: some-name: commands: # Checking out code to the ~/build directory - checkout-code ~/build # Storing the directory "vendor/" in the repository cache # with key dependencies. - store-in-cache repository dependencies vendor/ # Restoring the directory vendor/ again - restore-from-cache repository dependencies
This gives you in general greater flexibility to optimize your builds. For example, instead of storing a single cache file, you can store multiple different entries in your cache for different commands. Or, you can automatically invalidate your cache when you update your dependencies by adding a checksum to the cache key.
You can learn more about the options available in the dedicated caching section.