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.
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:
- 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.
- A post from a user mentioning Semaphore on Hacker News can be downvoted.
- 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.
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.
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.
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
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.
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.
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: