Semaphore Blog

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

Parallelism with up to 5 threads available

Get future posts like this one in your inbox.

Follow us on

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!

Semaphore can now parallelize your builds

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.

Processors

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

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.

Get future posts like this one in your inbox.

Follow us on