Semaphore Blog

News and updates from your friendly continuous integration and deployment service.

SSH Access to Your CI Environment

Get future posts like this one in your inbox.

Follow us on

With great pleasure we are announcing the release of a new tool on Semaphore) — the ability to SSH into your CI environment.

SSH access to your CI environment

As of today, you are able to interactively inspect and run commands in the Semaphore environment right from your terminal.

This new feature enables you to easily find the subtle differences between your local development environment and the Semaphore platform that are a frequent cause of hard-to-debug build failures.

If your project has a complex setup for its build environment, an SSH session can also be of great help. After inspecting the environment and making your tests pass in the SSH session, you can easily copy the steps and configuration for your automated builds.

Starting an SSH session

To SSH into the Semaphore environment, open one of your recent builds and look for the Launch SSH button to start a new build environment.

Starting an SSH session on Semaphore

Semaphore will start an environment identical to the one of your current build or deploy:

  • Your project’s Git repository will be checked out at the same revision.
  • Semaphore will also export any configuration files and environment variables which you have configured in your project’s settings.

Note: The first time you launch a session, Semaphore will guide you through the process of setting up a public key. You can find out more about setting up public SSH keys in our documentation.

We’re rolling this feature out to all users in the coming days.

We hope that you will enjoy this feature as much as we do. Happy SSH-ing!

Visualizing the Deployment Pipeline

Today we’re rolling out a refresh of server pages on Semaphore. Servers define a deployment pipeline from your Git repository, going through a build on Semaphore to make sure all tests pass and finally to a deploy to your staging or production server(s). They also make it very easy to get an overview of how much you are shipping.

New server page for continuous deployment on Semaphore

In this redesign we focused on making the pipeline clear with three distinct elements: a commit, build and deploy. We tried to do that in the previous incarnation, but eventually realized that every line in the feed was composed in a way that is hard to grasp.

Improved readability

We also wanted to make the deploy history easier to read. We realized that in practice most of the builds that are being deployed originate from a “merge” commit. While Semaphore lets you write a custom deploy message in case of a manual deployment strategy, in case of fully automated continuous deployment this is currently not possible. And if you are using GitHub, that means that most of the deploy messages look something like this:

Merge pull request #1256 from renderedtext/ma/pray-that-branch-name-is-very-descriptive

For this reason, deploy history now shows the first line below the merge information, as you can see for example in the “current deploy” block:

Expanded current deploy message on Semaphore

Start deploying from Semaphore

If you are not deploying through Semaphore yet, now is a good time to start. It saves your team a lot of communication overhead as it is completely transparent what was deployed and when. The deployment process is one click away for the whole development team, which is very important if your goal is for developers to own their features completely.

We have actually been deploying the main Semaphore web application continuously from master, and it has added relief, rather than stress to our workflow. In this case, every git push to master triggers a build, and if all tests pass the build automatically triggers a deploy.

Note that if you are worried about everyone having deploy access, you can easily create an organization team with reduced access rights.

We hope you like this change more than your average change of the Facebook feed. Feel free to let us know what you think, either in the comments below or the regular support channel.

Platform update on January 20th

The upcoming platform update is scheduled for Tuesday, January 20th, 2015.

Chromedriver is updated to version 2.13.

Elasticsearch is now on version 1.3.7.

MongoDB gets an update with version 2.4.12.

RethinkDB is updated to 1.15.3.

Scala is now on version 2.11.4 in which 54 issues are solved compared to version 2.11.2.

Trying the new platform

By selecting Ubuntu 14.04 LTS v1501 (release candidate) in Project Settings > Platform, you can try out this platform update right away. To avoid any problems during the final release next Tuesday, we encourage you to try out this release candidate so we can make the necessary fixes if needed.

A full list of changes is available in the platform changelog.

Ruby 2.2.0 Available In a Minor Platform Update

We just released a minor platform update — v1412.1.

Ruby 2.2.0 is added featuring a better garbage collector and other performance improvements.

Erlang has been updated to version 17.4.

Elixir is now on version 1.0.2.

Git received a new version with 2.2.1 with important security fixes.

JRuby is updated to 1.7.18 with a main goal to improve compatibility with Ruby 1.9.3.

PostGIS is now on version 2.1.5.

PHP receives multiple updates with 5.4.36, 5.5.20, 5.6.4.

NodeJS gets two updates with versions 0.10.35 and 11.14.

A full list of changes is available in the platform changelog.

Smarter Email Notifications

After recent introduction of default email notification settings and consolidation in one tab, today we are happy to announce more improvements.

With verified emails, you are now able to safely register all emails you would like to use to receive build and deploy status notifications.

Most importantly, we are making it possible to receive notifications only for the branches to which you contribute. This is very useful in larger teams with lots of activity going on where getting emails for all branches quickly becomes overwhelming.

Receive email only for your work

Email notifications for big teams can be a bit noisy. That is spoiling the way of getting information about status of builds, for many people.

Who would not like to receive notifications only for his work, and ignore the noise made by other members of the team?

You’re now able to subscribe for build notifications of only the builds that contain your commits. Semaphore matches your work via committers email address and your personal (verified) email address.

If you commit via various email addresses add them to Semaphore account and upgrade your notifications policy to “My work”.

Email Account Menu - My Work

You can find “My work” policy under project’s email notifications settings, or new “Notifications” tab under Account settings.

Email as a first class citizen

We are introducing a way to add, verify and remove multiple emails to be used for notifications. You can find this screen in your Account Settings. Each new email you add needs to be verified. Once you do that, the email can be selected as an option in notification settings.

Email List

Another new feature is “Primary email address” which represents your main email address. By default, the email you use to sign in is set to be your primary email address, used by default for notifications on all projects.

If you open the Account Settings screen, you will notice that we’ve already migrated all email addresses that you have used on Semaphore so far. That means that for most users there will be no need for any migration process, or manual actions.

Feel free to let us know what you think about these improvements.

Happy building!

Platform update on December 23rd

The upcoming platform update is scheduled for Tuesday, December 23rd, 2014.

Bundler is updated to version 1.7.9.

Firefox is updated to version 34 which requires all projects using the selenium-webdriver gem to update it with bundle update selenium-webdriver.

Git is now on version 2.2.0.

libmysqlclient is updated to version 5.6.22.

PHP gets three version updates with 5.4.35, 5.5.19, 5.6.3.

Redis is now on version 2.8.18 which includes various new features and bugfixes.

New things

Go is now installed by default. The included version is 1.4, which among other things, adds support for Android applications.

Trying the new platform

You can evaluate the new platform right away by selecting Ubuntu 14.04 LTS v1412 (release candidate) from the Platform section of Project Settings. We encourage you to try it out, so that we can iron out any issues you may find along the way until the final release on next Tuesday.

A full list of changes is available in the platform changelog.

Queued Builds Cancellation

Last week we introduced high priority branches. Today, we’re introducing a new feature that gives more control over the build queue - queued builds cancellation.

Queued Builds Cancellation in Semaphore Continuous Integration Service

With queued builds cancellation strategy, if you push few times to a branch you don’t have to wait for all builds to complete to get the build results of the last code version. Instead, queued builds will be cancelled and only the most recent version of the code will be tested.

You’ll find the screen to configure this in your project settings, Branches tab.

Queued Builds Cancellation Settings in Semaphore CI

With queued builds cancellation you don’t need to hold your pushes or to cancel builds manually. Just push when you like and get the latest results as soon as possible.

Happy building!

High Priority Branches

Semaphore features a custom build queue algorithm that was designed to make the build flow for a team as pleasant as possible. A developer that pushes frequently won’t be able to “hijack” Semaphore for him or herself. Instead, builds will be shared across the team making everyone happy and productive.

Even though the algorithm serves us well, being mostly invisible, some teams need more control over the build queue. Today we’re introducing high priority branches.

Priority Branches in Semaphore Continuous Integration Service

With high priority branches you can choose one or more branches that will be scheduled before others. They can be specified with a list of regular expressions. For example:


will match hotfix-start-build and master as high priority branches.

We recommend setting only one or two branches as high priority since adding more can make the algorithm insignificant.

You’ll find the screen to configure this in your project settings, Branches tab.

Priority Branches Settings in Semaphore Continuous Integration Service

With high priority branches you will be able to build and deploy important code as soon as possible. We’re working on other improvements in this area, so stay tuned for more.

Happy building!

Updated PhantomJS 1.9.8 In a Minor Platform Update

We just released a minor platform update — v1411.1.

The official release of PhantomJS 1.9.8 had an issue with guard-jasmine tests which required a custom compilation of PhantomJS 1.9.8 because there’s a very slim chance that it will be officially released. The binary in this platform update includes the fix.

New things

RabbitMQ is now included in the platform.

If you experience any issues, please let us know immediately so that we can fix them as soon as possible.

A full list of changes is available in the platform changelog.

One Place for All Email Notification Settings

Today, we’re releasing a new way of managing email notifications on Semaphore.

Now you can update your project notification settings from one place, and set a default email notification policy for all projects you or your colleagues add in the future.

You’ll find the new notifications tab in the account menu.

In front of the whole team I would like to thank all the folks that have shared their experiences and workflows with us.

We know that notifications can be a big part of your CI setup, so we will be further refining our notifications system to make it even better. Stay tuned, more updates coming soon.

Get future posts like this one in your inbox.

Follow us on