NEW Run your Ruby tests in a few minutes and ship faster with Boosters, one-click auto parallelization · Learn more…

Semaphore Blog

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

Semaphore can now parallelize your builds

Get future posts like this one in your inbox.

Follow us on

We’re very excited to announce that build parallelization in Semaphore is now available to all trial users and customers with Pro 2 plan and higher.

How does it work?

When adding a new project or editing its’ build settings, you can schedule your build commands to run in multiple threads:

That’s it. Now Semaphore will run all Setup plus Thread #1 commands in one thread, and Setup plus Thread #2 commands in another:

At the moment the limit is two threads, but the plan is to make more available.


Our pricing scheme is unchanged, but we’ve introduced a new term - processor - to explain our offering more clearly.

What we used to call “concurrent builds” is having two processors available to run two builds simultaneously:

The difference now is that if your subscription allows more than one processor, you have an option to parallelize a single build:

What we saw in practice is that projects with longer test runs benefit greatly from parallelization (as their total build time has decreased), but we’d keep the smaller projects on a single track. So various projects come and go through the available processors:

These images are taken from our refreshed features page.

We hope you’ll enjoy this feature and that it will save you some time in development.

Semaphore API grows

Today we’re pleased to announce two more methods in Semaphore API: one for listing all projects that you have access to, and another that returns full branch history.

Basically, these correspond to the dashboard and branch pages on our web front-end.

Check out the revised API documentation for more on how to access those and what data is included. We can’t wait to see all the interesting ways you use it! As always, if you have any feedback, please do tell us.

New notifications screen in Semaphore, Flowdock integration

Making it easy to set up build notifications on Semaphore has always been important to us. So far when we’d add a new notification type, we’d create a new tab for it in project settings. We knew that won’t work well forever, and time has come for change:

All notifications types are now part of a single tab in project settings. When you set one up, it appears ticked so that you know what to look for when you revisit.


Flowdock integration has been available for a few weeks although we haven’t announced on the blog yet. It’s simple, just enter the project name you’d like to appear in your flow, the API key for your flow and you’re set (we’re using the Team Inbox API):

Semaphore API

It’s been a while since we’ve announced the availability of build status API on Twitter. Here I’d like to let you know what it is exactly at the moment and what we plan to do in the future.

The methods

The API is very simple - right now there are only two methods. One gets you a list of all branches on a project, and another returns the current status on a requested project and branch.

You can easily copy the working URLs in your project settings:

Planned improvements

Our users have already been doing cool stuff with the API. Pivotal Labs have added support for Semaphore projects on their dashboard app.

Build status method returns only last completed build’s status, but we’re going to change that soon. For instance, you may not want to allow deployment of a branch that is still building.

We’re also going to expose the full build history via new method(s).

We’re happy when we receive a request to expand the API, so please contact us if you need something.

One more thing

If you’d rather to be notified when a build is finished, you can subscribe a HTTP endpoint to a post-build webhook. Semaphore will send a POST request with information about the build. We’re also planning to add pre-build webhooks, so that you know when a build has started.

Live build log and other UI improvements in Semaphore

Since we started the Semaphore project, we’ve always strived to come up with a good design. Continuous integration (CI) was not a new concept, but we saw a lot of room for improvement in how it’s done. We hoped that eventually more projects will use CI, which would benefit our entire industry. For example, with the assumption that code is on GitHub, we were able to design a compelling point and click workflow of adding a new project to the system, which has been copied by a few other services (we take imitiation as flattery).

The interaction doesn’t stop there of course. It’s important to be able to do what you want quickly and intuitively - when you’re waiting for a build, changing its settings or looking up why it failed. Thanks to our awesome users we learned and applied a couple of things that make this easier.

The dashboard

Doesn’t look much different, but here’s the catch:

  • The build status label is now clickable.
  • In case you have a build in progress and one or more enqueued ones on top, we show the “building” label for that branch.
  • Clickable areas around these elements have been slightly expanded.

The branch

The build table used to be coded in a way that made the entire row clickable. One bad side-effect was that it was not possible to open a build from here on iPad.

We’ve changed this completely. As you can see, more information is shown about each build. Build number, status label, timestamp are separately clickable, or tappable.

There’s also a link to project settings at the top. The project settings page will be aware that it should take you back to the branch once you’re done changing your build commands, for instance. We hope that this makes the process of setting up a project, for which we could not guess build commands, easier.

The build page

This is a build in progress. We finally have a live build log. It’s not just sexy but useful when you’re simply wondering where your build is at, for whatever reason.

Apart from that:

  • Same as on the branch page, we’ve included a link to project settings on the top.
  • The branch name is a clickable link.
  • The commit rows are now clickable only around the commit hash.
  • Only the newest three commits are displayed, top to bottom, with an option to show more.
  • The build’s full git revision is shown.
  • If you open a red build, the failed command’s output is scrolled to the bottom by default, so you can see the reason right away.
  • Queued builds can be deleted.

We hope you’re enjoying these UI changes in Semaphore. We have more news to come soon!

You can also follow along what we’re up to on Twitter.

Semaphore gets a better Solo plan, supports PhantomJS, Firefox 13, PostgreSQL 9.1, HipChat

Semaphore, our hosted continuous integration service, is being continuously improved. Here are the highlights of what’s new since our last post.

Build environment improvements

We’ve upgraded our build environment, making PhantomJS, Java, Sphinx and Memcache, among others, available out of the box.

There’s a more complete list on our documentation site, and we know quite a few people who will benefit from PostgreSQL 9.1 and Firefox 13.

If you’re using MySQL or PostgreSQL, Semaphore now also exports some environment variables that make the database name, user and password available. You may use them if your build requires some custom scripting.

A better Solo plan

We’ve changed how our Solo plan works - from $9 with no collaborators to $14 and unlimited collaborators. While we’ve thought hard about pricing before we’ve announced it, it’s a learning process. Our goal for the future is to make pricing changes that will give our users even more bang for the buck.

Invite collaborators after adding a project

Semaphore knows about your collaborators from GitHub automatically. You can invite them while you’re adding your project, and when they sign up it is waiting for them on their dashboard.

Now we’re introducing a feature that lets you invite them from project settings as well:

This will be useful if you decide not to invite them while you’re adding a project to Semaphore.

HipChat notifications

As a project owner you can now set up Hipchat post-build notifications. The procedure is very similar to how Campfire works and what you’re used to if you’re a Hipchat user.

The road ahead

Beginning of an API, JRuby and post-build webhooks are just around the corner, as we move on to a live build log and even bigger things in our mission to make continuous integration a compelling experience for all developers. Watch this space or follow @semaphoreci for further updates.

Campfire notifications and more Ruby versions now available in Semaphore

Hot on the heels of Semaphore’s public launch, we’ve shipped two important and frequently requested features so far: Campfire notifications and support for different versions of Ruby.


We’re big fans of Campfire and use it both for our internal communication and on some client projects when it makes sense. As we’ve heard from our users, this process is fairly common, and we’ve made it as easy to have build notifications come from Semaphore to your Campfire room as you’re used to on other web services. Go to your project settings, open the “Campfire” tab and fill in the blanks:

After that you will receive messages such as this one:

The message includes project, branch name, author of the last commit and its’ message. The behaviour is the same as with emails - first build of a branch is always sent, after that messages are sent only if there’s a change in build status.

More Rubies

As we’ve explained in previous post, limiting ourselves to support only Ruby 1.9.2 was just a matter of cutting down the MVP. However, we’re aware that many people now work with 1.9.3 or are still on 1.8.7, and we’re very happy that we can announce support for these versions so quickly:

Feel free to let us know how this works for you. Happy building!

Semaphore launched

A couple of months ago in a blog post Introducing Semaphore we explained what drove us to start working on Semaphore. For those of you who don’t know, Semaphore is hosted continuos integration service for Ruby applications. Now we are launching it as a complete, but ever-evolving product and I want to talk a bit about what happened in between.

Evolving the MVP

Close to two hundred people signed up to beta test Semaphore. We invited a better part (sorry if we haven’t invited you early), and those who were invited actually became a part of our team in a way. Beta testers contributed immensely to what is Semaphore right now. From some tips like minor UI improvements to brainstorming about pricing. Thank you so much people and I hope you enjoyed it as much as we did.

When the beta period started we had just one build server and were supporting just Rails projects with MySQL and PostgeSQL. We of course knew that it was an extremely limited subset of all technologies on the market. But we wanted to simulate BDD also in company and product development. So we intentionally built and supported less and added more only when we felt a strong need for an additional feature.

Although that initially led to a high number of feature requests, it also enabled us to launch the product in reasonable time and with limited resources while keeping most of our beta testers, now customers, happy.

When saying happy, I really mean that they are happy-happy. We of course believed that there are people who will like seamless GitHub integration and polished interface, but we never expected frequent emails where people will actually say “Thank you for building such a great service”. I don’t know, maybe it’s really true that developers are that nice; I haven’t worked on a product for developers before.

A bit into details

  • “Only Rails” was way too rigid. We now support any Ruby project.

  • Connected with only Rails idea, we didn’t have custom build commands. This is definitely something that is needed for CI. We were probably blinded a bit in this area by how little configuration is possible on Heroku to work great. But it’s not like all people use Rails and Heroku all the time, there are many custom stand alone applications.

  • Only MySQL and PostgreSQL. Although you might think this was a huge limitation, it was totally the opposite. Seems like the NoSQL hype is over and that relational databases still work for most of the projects. Situation with databases on Semaphore now is pretty much - you name it, we have it. But it was a good call that we didn’t worry too much about them in the beginning.

  • Only 1.9.2. Just fine! And yes 1.9.3 is available on request, but will be available through a select box very very soon.

  • Adding and removing branches was manual at first and now it’s automatic through GitHub web hooks and people love it.

  • One fast machine with on-demand virtualization and no algorithm for supporting N machines. Right call. Once we understood bottlenecks of hardware we addressed the problem and Semaphore is now successfully running on a couple of high-performance build servers.

  • Pricing! This one was really tough. It’s still early to say if we got it right. Overall people are OK with it. For this one you can think and brainstorm with your team as much as you would like but you will not move forward until you talk with your potential customers. We probably read that advice here and there a couple of times but didn’t really understand it until we really faced it.

If you read this far, check it out at, our customers say it’s a good CI solution and we would like to hear you opinion.

Semaphore gets customizable build commands

Since we launched Semaphore as private beta a month ago we have received a lot of positive feedback along with many feature requests. We saw various projects, and realized that many people need to do something in the test suite that we cannot guess. Or simply want to build a Ruby project that is not a Rails app.

Today we are introducing project analysis with custom build commands. Analysis is a step that Semaphore performs on every new project. During analysis it tries to learn as much as possible about your project and the output is a set of build commands that match your application. Build commands can be reviewed and changed before the build process begins in case Semaphore misses something specific to your application.

Typical use cases for custom build commands that we have seen so far are:

  • setting up custom database configuration files
  • calling a custom rake task for setting up seed db data
  • passing special flags to default rake <test_framework> tasks
  • exporting environment variables that contain sensitive information which you don’t want to keep in your repository

An important side-effect of this is that Semaphore can now build any Ruby project!

We’re currently letting the next wave of beta testers in, so if you haven’t applied already, shoot us an email to

Get future posts like this one in your inbox.

Follow us on