Working With Branches

Do you use multiple branches in your project? For example, keeping master always deployable and using a develop branch for breaking changes? Or topic-branches – one for each new task or feature?

Per-Branch Configuration

You can manage CI settings on a per-branch basis from the web UI. To configure branches for a repository, go to your dashboard and then click on the gear icon for the repository. The settings on the “When To Build” and “Configure Existing Branches” pages determine when builds will be triggered by CI events such as incoming SCM event notification webhooks.

Solano CI branch configuration

When the CI mode is “ON”, push and pull request CI events will trigger builds, while if it is “PR”, only pull request CI events will trigger builds.


CI events will only trigger builds if both the branch’s settings and the repository’s “When To Build” settings allow it.

Branches will automatically be changed from “Visible” to “Hidden” after a period of inactivity, unless it is “Locked”. A “Pinned” branch will be listed on the Solano CI Dashboard above “Unpinned” branches.


You can use the solano command to setup Solano CI to work with a branch (for example, newfeature), switch to that branch (or create it) and use the solano suite command:

$ git checkout [-b] newfeature
$ solano suite

If you already have a suite set up for this branch, you’ll be prompted to re-use it. You can edit the configuration with:

$ solano suite --edit

You can have multiple Solano CI “suite” configurations per repo – in fact, you can have multiple per branch if you’d like to maintain different configurations.