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.

Automatically run your Cucumber tests in parallel with cucumber_in_groups

Get future posts like this one in your inbox.

Follow us on

Our great customers from Cloud Castle have created a nice gem called cucumberingroups. If you follow the simple instructions, you’ll be able to parallelize your Cucumber test suite on Semaphore with just the following build commands:

GROUP=1of2 bundle exec cucumber
GROUP=2of2 bundle exec cucumber

Provided that you schedule them in separate threads, this will automatically split the features into two or more groups and run them in parallel. It’s so much better than any kind of manual maintenance.

Happy building!

Why we don't play dirty to market our product

When we launched Semaphore, the market for continuous integration services was ripe for change. Existing solutions were excessively complicated. Emerging hosted solutions offered, in our opinion, a poor user experience at needlessly high prices.

Hosted developer services used to live in a quite peaceful market, with very few competitors who are likely serving a different audience. For example, Airbrake has been the only credible exception tracking service for years. This is now changing with hosted CI services being a good example, as a couple of services have arrived shortly one after another.

At the same time many founders are deciding not to bootstrap their product but get funding as quickly as possible, which introduces some new problems for the founders and customers.

We’ve noticed that this has created some unusual marketing behaviour:

  1. When someone would tweet to @semaphoreapp, a competing cofounder or service account would often jump in the conversation asking the user to leave Semaphore for their service.
  2. A post from a user mentioning Semaphore on Hacker News can be downvoted.
  3. Spreading misinformation, for example by repeatedly claiming that one’s service is the fastest, while a very simple test shows otherwise if you actually do a comparison.

We feel that this is unethical and so we do not do it, nor ever will. When we speak we will stick to the facts, because we are proud of what we have created.

API for build information and build log

We have added two new endpoints to our API which allow users to get more information about a build.

Basic build information is available via Build Information endpoint and the build’s log can be fetched via Build Log endpoint (which also includes build’s basic information).

URLs to these endpoints are now included in the resposes of other API requests where appropriate, ie whenever a build is referenced.

The API documentation has been updated accordingly with these latest additions.

There are also new environment variables available during the build:


These can be used to construct an API URL in a custom hook after the tests have run, for example.

We’re very happy to see more projects using our API. Since its introduction, we’ve served over 4 million API requests, and almost a quarter of those has come in the last week alone.

Heroku add-on update and new blog

Welcome to the Semaphore blog! We’ve realized that it’s time to separate from the Rendered Text blog, where we’ll continue to share other news and engineering stories from the company.

Now you can follow new articles on Semaphore via Atom feeds - eg you can follow only platform updates if you’re interested - and you can also check them out from a new navigation element within the application:

In other news, our Heroku add-on is in beta, and it’s a great way to integrate your application on Heroku. Big thanks to all users that have been test-driving it so far! We have just updated the app for the latest Heroku SSO API, and got just one more permission issue to resolve for people who have had an expired free trial on Semaphore before. We’re expecting to hit public beta and announce plans soon.

Semaphore pricing update with higher plans

As our service continues to grow, we’re seeing more and more companies coming aboard with developers working on many branches simultaneously. If we combine that with the possibility of running tests in parallel, it becomes clear that we need to offer more.

Fortunately we are also in the stage when we are confident in delivering more capacity, so today we’re introducing four new plans with 8, 12, 16 and 24 processors available.

We are also phasing out the Pro 5 plan for new users; current customers who are on that plan can continue to use it indefinitely.

CLIs and tools for Semaphore

We’re very excited to see command-line tools and libraries being developed on top of Semaphore API. Aleksandar Diklić, who has joined Rendered Text recently, hacked a script which eventually became available as semaphore-status:

Almost at the same time Sam Saccone announced semaphorestatus made with Node.js:

Next up we have semaphoreapp, a gem from Alessandro Morandi which lets you get build information about your projects with a little bit of Ruby code:

project = Semaphoreapp::Project.find_by_name('yourapp')

Peter Vandenberk has started git-semaphore, a gem that integrates Semaphore into your git workflow:

# list your projects:
git semaphore --projects

# list current project's branches:
git semaphore --branches

# status of current project + branch:
git semaphore --status

Thanks guys for these awesome contributions! If you have something similar in the making, please tell us via email or at @semaphoreapp so that we can share further.

Parallelism with up to 5 threads available

Since the launch of parallelism, we’ve seen many users embrace the ease of splitting their builds into threads. We had set a limit of up to two threads per build, to learn how people use them and make sure our platform handles everything without problems.

Today we’re happy to announce that users on Pro 3 plan and above can now schedule their build commands in as many parallel threads as their plan has processors. That means that you can run unlimited builds with 3x parallelization for just $129/month.

Many thanks to our awesome customers!

Passwordless sudo for all

One of the goals we had with the recent platform upgrade was to have the infrastructure in place so that we can allow all customers to install additional software and tweak configuration settings by themselves.

Our practice so far has been to enable additional packages or configuration on your request. This has worked well in most cases, and has led us to see which libraries people frequently need, which in turn helped us learn how to enrich and evolve our build stack. That’s our approach in general: start with something small we’re sure about, then listen and learn to how improve it.

It obviously has the downside of having some back and forth with our customers, which 1) doesn’t scale and 2) doesn’t work if customers are not sure what they need. So today we’re taking a step forward and allowing everyone to have build commands like sudo apt-get install -y awesomeness.

We’re also introducing a small change in the UI: if you’ve arranged your builds commands in “Setup” and “Thread #X”, then you’ll see the passed setup commands initially hidden:

Green setup commands hidden from build results

Current customers with a custom setup arranged over our support channel will see it become part of their editable build settings over the next day or two.

You’ll see that installing additional components doesn’t take much time on Semaphore. For instance, setting up a custom Redis server from a PPA takes less than 10 seconds, while packages from the official Ubuntu distribution channels take even less. We’ll be monitoring the custom installation commands in order to continue improving our build stack and provide the best hosted CI experience for our customers.

Build platform upgrade

Today we’ve rolled out an upgrade to the Semaphore build platform based on the latest Ubuntu LTS (12.04). This means that versions of pretty much everything went up. Check out our version information page for details.

Some highlights:

  • Firefox is now at version 18: if you’re using Selenium then make sure you’re running the latest version of selenium-webdriver gem (2.27+), or you’ll see random timeout errors.
  • Ruby version patchlevels have also changed, as we’re trying to follow Heroku on the provided versions. Make sure you’re running the latest version of debugger gem (1.2.3).

By popular demand, we also added the following new software to the default stack:

  • Elasticsearch
  • Chrome and chromedriver

After this we’re planning to enable passwordless sudo for all users (currently available on demand) for easier setup of additional packages.

About that downtime

Last but not the least, we’re deeply sorry for the downtime we had yesterday from about 19:27 UTC. A few servers had network issues and our notification setup failed, so we didn’t react on time. We’re taking all measures to make sure this does not repeat in such a way again.

Thanks for all your support!

Skip those builds

Sometimes when you’re using Semaphore you want to skip building some commits or branches. Here’s how you can easily accomplish that.

If you’d like your commit, or a series of commits that you’re pushing, to not trigger a build, just write [ci skip] somewhere in your commit’s message. This useful for designers, for example:

Today we’re launching a way to turn off or filter automatic builds on new branches. You can either turn off automatic builds of new branches, or you can specify a whitelist of allowed regular expressions. In that case a new branch will be built only if it matches one of the entries. You’ll find this in your project settings:

Happy building!

Get future posts like this one in your inbox.

Follow us on