Semaphore Blog

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

Setting up Jasmine JavaScript tests for continuous integration

Get future posts like this one in your inbox.

Follow us on

If you are writing JavaScript or CoffeeScript and want to practice TDD, probably the best option for you to implement automatic tests is Jasmine. There are a few nice articles to get you started with the framework (like How do I Jasmine: a tutorial and Testing Your JavaScript with Jasmine) and even a book JavaScript Testing with Jasmine.

Unfortunately it is not so obvious how to get your Jasmine test suite up and running on a continuous integration server such as Semaphore. Here we’ll show you how, assuming that you already have a basic Jasmine test suite in place, written in CoffeeScript as part of a Rails 3 app.

There are several ingredients needed to run a Jasmine test suite in CI:

  • Jasmine - BDD testing framework for JavaScript.
  • Jasminerice - handles Rails assets pipeline which makes CoffeeScript testing a breeze.
  • Guard::Jasmine - for headless testing with PhantomJS.
  • PhantomJS - a headless WebKit scriptable with JavaScript or CoffeeScript. Already available on Semaphore.
  • Sinon.JS - for mocking server responses (optional).

Steps

Add Jasminerice and Guard::Jasmine to your project’s Gemfile:

group :development, :test do
  gem "jasmine"
  gem "jasminerice"
  gem "guard-jasmine"
end

Bundle and than bootstrap Guard::Jasmine:

guard init jasmine
mkdir -p spec/javascripts
echo -e "#=require application\n#=require_tree ./" > spec/javascripts/spec.js.coffee
echo -e "/*\n *=require application\n */" > spec/javascripts/spec.css

With everything in place you are ready to run your tests on a CI service with guard-jasmine command. Semaphore will include test results in a report:

Visit the tools’ pages for more info. There are a lot of instructions that cover specific needs that your project might have.

Heroku add-on goes public

The Semaphore add-on for Heroku is officially out of beta. The add-on makes it easy to set up continuous integration (shhh and soon deployment) for your Heroku-hosted Ruby app.

Big thanks to all the people who’ve used and provided feedback on the add-on while it was in beta, and of course Heroku for the opportunity and great collaboration.

Check it out.

Introducing the project timeline

Sometimes you just want to follow a single project. Or you’d like to catch up and see what’s been happenning. Who’s been busy? Who broke the build and when was it fixed?

Today we’re rolling out project pages with a timeline of all activities at a glance.

The project page begins with a list of its branches, just like on the dashboard. It is followed by the timeline, showing chronologically who pushed what to which branch and the corresponding status. Updates about new and removed branches are included. Everything is live updated. It is a great way to follow your team’s progress.

You can access the project page now from the dashboard, branch and build pages. We’ve been test driving this feature for a while, so you’ll see a nice bit of history of your projects already. We hope you’ll enjoy this feature as much as we do.

ProjectMonitor, BuildHeroes and Coveralls integrate with Semaphore

Here’s a quick roundup of 3rd party tools that let you get more out of Semaphore:

ProjectMonitor is a CI display aggregator for big screens or TVs. The idea is to see the status of all your projects’ builds in highly visible fashion. It’s an open source app that you can run on your own server.

BuildHeroes provides build leaderboards and statistics for your team. After you set up a post-build webhook, it will calculate your build success rate, keep track of developer scores and more.

Coveralls provides code coverage as a service, from repository-wide overviews to line by line data. It can also post a coverage summary to your pull requests on GitHub.

If you’re also making your app or library work with Semaphore by using our API, let us know. We’ll tell our customers about it on this blog.

Automatically run your Cucumber tests in parallel with cucumber_in_groups

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:

SEMAPHORE_PROJECT_HASH_ID
SEMAPHORE_BRANCH_ID
SEMAPHORE_BUILD_NUMBER
SEMAPHORE_REPO_SLUG

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')
project.branches

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.

Get future posts like this one in your inbox.

Follow us on