The solano Command

Logging in with “solano login”

The solano login and solano logout commands connect your local workspaces with Solano CI.

Login credentials are stored in ~/.solano, and are currently user-wide.

Selecting a Solano CI server

By default, the solano command will communicate with If you have a Solano Private CI installation with a different hostname, you can use the solano server:set command to record a hostname to use. You can also save various other connection parameters, as documented by the command’s built-in help.

Password-less Github Accounts

If you’ve signed in via Github, you haven’t set a password for your Solano CI account. To log in via the CLI, you can use an authentication token available from the “Login Token” menu item on the “User Settings” menu. The “User Settings” menu is accessible from the drop-down menu in the upper right hand corner of the web interface.


Tokens are one-time-use and automatically expiring.

Switching Between Accounts

At present, to switch between multiple Solano CI accounts, you will need to log out from one and log in with the other. We’re working on a more flexible solution here, and we appreciate your feedback.

“solano run”

Solano CI uses test patterns and command lists to decide what to run.

A test pattern is a list of Ruby globs. For example:

spec/**_spec.rb, features/**.feature

When you run solano suite to configure a test suite, you’ll be asked to enter the default test pattern for the suite.

The test pattern you save with solano suite will be used for the suite’s CI builds.

If you need a more complicated test pattern, you can supply it in the config/solano.yml file.

When you run tests in Solano CI interactively using solano spec or solano run, it will also use the suite’s default pattern.

You can run solano run with an argument to select specific tests:

# Select tests from within a directory
$ solano run 'spec/mymodule/*_spec.rb'
# Run a single test
$ solano run spec/selenium/login_with_selenium.rb
# Jasmine Webkit tests
$ solano run 'spec/javascripts/**/*_spec.js'

The --test-pattern command option works exactly the same as supplying a pattern argument. If you use the --test-pattern option, it will take precedence.

“solano rerun” and “solano describe”

A common workflow pattern involves making a commit, running the full test suite to see whether the commit has broken anything, and then iterating on follow-up commits to resolve test failures.

To locally re-run failing tests, you can use the solano describe command and a little bit of shell-scripting:

$ rspec `solano describe $session_id --names --type=rspec`

In some cases it may make more sense to re-run tests in Solano CI. You can do this either manually with solano run --test-pattern=relative/path/to/test or using the solano rerun command. In both cases, a new session will be created that references the current local version of the code.

The solano rerun command supports this workflow by starting a new Solano CI session that will run only the failed tests from an existing session. Note that you must invoke the command from a local checkout of the correct repository and branch. The new session will use the current local version of the code.


solano rerun is pretty simple right now - it doesn’t do much in the way of local sanity checking, so if you tell it to rerun the tests for the wrong repo, it’ll happily try.

One particularly effective way to use solano rerun is to make and commit a local change to fix a set of tests and re-run only the failing tests from a previous session. Using this approach you can iterate until most or all tests pass and then squash the local commits before pushing the change to an integration branch. Each successive re-run session will use your local changes without disturbing other collaborators on the branch.