The solano Command¶
Logging in with “solano login”¶
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
solano server:set command to record a hostname to use. You can
also save various other connection parameters, as documented by the command’s
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 CI uses test patterns and command lists to decide what to run.
A test pattern is a list of Ruby globs. For example:
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
--test-pattern command option works exactly the same as supplying a
pattern argument. If you use the
--test-pattern option, it will take
“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
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
--test-pattern=relative/path/to/test or using the
command. In both cases, a new session will be created that references
the current local version of the code.
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