After announcing Signal, one of the firsts feedbacks I received was from Raphael, asking if I was planning to add a feed compatible with CCMenu.
I found the functionality very interesting and today, in order to integrate Signal with CCMenu (OS X) or CCTray (Windows), you just need to point to the URL http://host/projects/status.xml and select the desired project.
I recorded a short video (01:13 minutes) demonstrating how to configure the tool and how it works, hope you like it:
Signal is a continuous integration server written in Rails which I think takes the best features of similar systems and merges them in a very simple to use application.
When I started working with Rails, the first continuous integration server I tried was CruiseControl.rb. The CC.rb was also written in Rails and what bothers me the most about it is that to add a project you have to connect to the server and execute:
After running the previous command you can open a YAML file and configure the recipient of the emails that are sent by the application when the build breaks. In the scaffolding land, this makes no sense to me. It’s much more simpler to have a page where any user can register a project without much difficulty, like Hudson, Integrity and Signal does.
Another thing that bothers me about CC.rb is that it creates a lot of cruise processes and sometimes they hang. For a while I thought the problem was only happening with me but after talking with some people I found it wasn’t so uncommon.
The third thing I’ll complain about CC.rb is that at the home page it shows the last five builds of each project. IMHO the last two builds is already too much information. To know that the old builds were broken or not doesn’t mean anything to me. The only thing I care about is to know if the project is in a good state or not, information that Integrity and Signal display very well.
Integrity does a lot of things in a cool way, but I don’t like the fact that to install it you have to download the gem and then execute a command. The worst thing is that depending of the server you want to use, the command takes different parameters. Before explaining why this installation method is a problem, let me confess that another thing I don’t like about Integrity is that it doesn’t come with email support. Besides this lack of support be ugly, to include it you have to download another gem and modify a file. It looks simple but didn’t work for me, apparently because the version of the plugin gem was not compatible with the version of the application gem. Now, how do you change the version of an application that was installed by executing a command from a gem? Would it only require to download the second version of the gem and delete the first? Would it require to reinstall the application? I don’t know, maybe I did something stupid but nothing worked for me and this is why I believe that this way of dealing with applications is a problem.
Signal tries to take advantage of Git. To install Signal you can run:
git clone git://github.com/dcrec1/signal.git
cd signal
rake inploy:local:setup
If you ever want to go back to an specific version you just can git reset –hard COMMIT; simple, and it can take advantage of history by knowing where we are and what we are undoing.
One characteristic CC.rb has and I miss in Integrity is to show the date of each build on the home page. Signal shows how long ago each project was built, so we can easily know when was the last build and if they are being created.
report_card is a project that integrates metric_fu with Integrity, but it’s necessary to install another application and run a few commands, what is very complicated to me. It’s for this reason I decided that Signal has native integration with metric_fu, RSpec and Cucumber.
Signal’s integration with RSpec, Cucumber and metric_fu is very simple. In each project page there are three links: specs, features, and metrics, which point to ROOT/docs/specs.html, ROOT/docs/features.html and ROOT/tmp/metric_fu/output/index.html, metric_fu’s default path. This means that if we are generating HTML specifications, they can be accessed from the project page.
Another integration that Signal has is with Inploy. If we want to deploy an application, we can do it from the project page by clicking on deploy, the rake task inploy:remote:update will be executed.
Hudson is an very good integration server, but I think Signal overcomes it by being a little more simpler to use and by being developed in Rails and being hosted on GitHub.
Being developed in Rails is an advantage because this type of projects usually have several plugins and Rails has native support to plugins. Almost every railer knows how to install a plugin and how do they work, so it will not be a problem to create them.
Being on GitHub is an advantage because it facilitates further collaboration with the project. As today, Signal has a lot of conventions, but if for some reason anyone need some special configuration, he can fork the project and start contributing. Since Signal was developed with Rails and it’s pretty simple, people will not have difficulties to understand how it works.
One of the conventions of Signal is that each build is created by running the rake task build, which depending of the project I have something like this:
I recorded a short video of nearly three minutes demonstrating how easy it is to install and use Signal. In the video I download the application and install it using Inploy. Then I register a new project and create a new build. The build is not automatically created along with the project because sometimes we need to perform some actions before running it. Just for demonstration purposes, I chose a project in Ruby that has a very fast build, given it does not run the Cucumber features neither the metrics. After the first build, I do start delayed_job and create a build from the command line, like being in a Git hook. The video ends with me showing a build of the project Signal and how easily it is to view the specs, the stories and metrics from the project page.
