Configuring With solano.yml


For quick-start configuration examples for specific languages, head over to Language-Specific Guides.

Read on for examples of other scenarios, like controlling which databases to start, setting environment variables, and setting timeouts.

Punctuation and spacing are meaningful in YAML. You should check that your YAML is valid and parses as expected. For instance, you can test your YAML online or with import yaml; print yaml.load(foo) in Python.

Solano CI will look for a solano.yml file, either at the root of your repository or in a config/ subdirectory, and load settings from the “tddium” section. A complete reference is available.

You can use this configuration file to control:

  • The setup procedure Solano CI will use to install, configure, and boot your app.
  • The tests (and other build steps) that Solano CI will run, either as list of glob patterns used to select or exclude tests to run by default (e.g., in CI) or as a list of commands.
  • The service subsystems (like Postgres, Memcache, Sphinx, Solr, or ElasticSearch) that are started for your tests. This control is mostly useful if Solano CI can’t properly guess what you’ll need running.

A sample solano.yml for a Ruby project is shown below:

# config/solano.yml
  - features/*.feature
  - features/api/*.feature
  - spec/**/*_spec.rb
  - test/**/*_test.rb
  version: '9.1'
  version: '5.5'
sqlite: false
  version: '1.8.1'

This configuration tells Solano CI to:

  1. Select cucumber features in the features directory and the features/api subdirectory, all specs and all test unit tests. In this example, there’s a features/paid_api directory that contains tests not meant for CI.
  2. Enable the Postgres subsystem, even if the “pg” gem is not in the Gemfile.
  3. Disable the Sqlite subsystem even if the “mysql” gem is in the Gemfile.

If a subsystem is not mentioned in the configuration file, Solano CI will probe for a dependency in your code (e.g., a Gemfile, requirements.txt, or packages.json) and enable the subsystem if and only if the corresponding gem is found.

If the subsystem is mentioned in the configuration and the value in the configuration is “false”, the subsystem will not be enabled even if your code lists a dependency. If the value is any value that evaluates to true, then the subsystem will be enabled unconditionally.

Some subsystems, such as the Postgres subsystem, allow you to specify a string value that specifies the version to start. See the documentation for each subsystem for further details.

Setting Environment Variables

Solano CI sets a number of environment variables for you automatically. A complete list of environment variables set by Solano CI is available here.

You can also set environment variables in your build environment. For non-sensitive values, we recommend adding key-value pairs directly to your configuration file. You can also use so-called config variables to store sensitive values such as API keys securely. More information on both methods is available here.