All configuration is held in YAML files, loaded in a specific order to allow for granular precedence.
Refer to the default config.yml for the available variables.
Global variables precedence
Variables are looked up for in the following places.
Default configuration file, created at installation time. Do not edit this file, it is meant to be managed upstream and to get updated.
The project configuration, relative to your project path, created as part of the boilerplate. It contains the main configuration for the project (software, versions, ...) and should be shared with the whole team, ie. commited in git alongside the codebase.
User configuration, local only. This is for your "personal" preferences, that do not need to be shared with others, but will be applied to all your projects. Use this for choosing your provider or shared folder options, storing your GitHub token, etc.
Note: you will need to create this file manually. Have a look into the "examples" folder included in the boilerplate for more details.
Custom project local configuration, relative to your project path. This is for options that you want to override locally, but only for a given project. It should be git ignored and not included in your project.
Note: you will need to create this file manually.
In addition to the variables from the mail config.yml file, a few Ansible roles (php, memcached, ...) use additional variables. Look for "default" folders in the codebase, eg. for php You can override any of these variables in any of the config.yml file described above.
The approach taken here was to avoid trying to expose too many variables and instead provides sane defaults. The rationale behind this is that having hundreds or thousands of variables to look for is not convenient, and would not be flexible enough to cover all use cases anyway. You can instead achieve any customization you may wish by using custom Ansible playbooks.