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.
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.
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.
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.
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!
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 https://semaphoreci.com, our customers say it’s a good CI solution and we would like to hear you opinion.
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 firstname.lastname@example.org