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!
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:
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.
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
- 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
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
- 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!
Sometimes when you’re using Semaphore you want to
skip building some commits or branches. Here’s how you can easily accomplish
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:
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
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
We hope you’ll enjoy this feature and that it will save you some time in
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
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
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
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):
It’s been a while since we’ve
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 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:
Our users have already been doing cool stuff with the API. Pivotal
Labs have added support for Semaphore projects on their dashboard
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
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.
Hot on the heels of GitHub’s announcement of Commit Status API, we’re pleased to say that we stayed some extra time in the office and shipped it in Semaphore.
What this means is that right after you open a pull request, there’s going to be an indicator whether a build on that commit is pending, passed or failed on 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.
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 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.