Custom Background ServicesΒΆ

Solano CI automatically configures and starts a large number of background services such for your application. In some cases you may need a background service that Solano CI doesn’t (yet) know about. Solano CI supports the notion of a custom or user-specified service that you can configure and arrange for Solano CI to start automatically. It is also possible that we’re already planning to support the service you need, so the first thing to do is tell us about it by sending e-mail to info@solanolabs.com – we’re happy to help and there are probably others wanting the same feature!

To configure a user-provided service you will need to update your config/solano.yml. Here’s an example:

---
custom_service:
  path: 'bin/myservice.rb'
  ping: true
  parallel: true

The configuration for a user-defined service consists of the path for a command to run and a set of flags.

  • The path configuration argument is the path to the script or binary for your user-defined service. If the path specified is a relative path, Solano CI will first attempt to expand it relative to the repository root and then relative to each successive element of the PATH environment variable. In the example, bin/myservice.rb is a ruby script in the bin subdirectory of your repository root with the execute bit set.
  • When the parallel flag is false (the default), only a single copy of your service is started. When the parallel flag is set to true, one copy of the service is started in each worker.
  • When the ping flag is false (the default), Solano CI will not wait for the service to start before running tests. If the service needs to be running before tests can start, e.g. if tests do not themselves wait, or if the service start script performs setup that tests depend on, set the ping flag to true. When the ping flag is set to true your script will be invoked with two arguments: “ping” and the worker index. The system will assume the service is properly started when the script exits with a status of 0.

A toy example service might be:

#! /usr/bin/env ruby
case ARGV[0]
  when 'start'
    puts "Hello, Solano CI!"
  when 'stop'
    puts "Goodbye, Solano CI!"
  when 'ping'
    # Exit status of zero means service is started for worker index
    puts "Checking if instance for worker #{ARGV[1].to_i} is started"
end

When your service script is invoked it will be given two arguments. The first argument will be the string “start” or the string “stop”. The second argument will be an integer identifying the thread number on the current test VM. Your script will receive the full set of Solano CI environment variables for its thread.

If you do not enable parallelism for the service, only one instance of the service script will be started and thread-specific variables will not be set in your environment.

If you need multiple services, you should write a single wrapper script that launches all of them for you. The service itself may be implemented by code checked-in to your repository or may be already installed in the virtual machine ahead of time.