At CustomInk, we use a variety of tools to monitor the status of our builds. One such tool was Greenscreen. In fact, we even wrote a blog post about how we use Greenscreen at CustomInk not too long ago.
One of the biggest problems with Greenscreen was its extensibility. By default, Greenscreen only works with Hudson and Jenkins servers. With Travis CI becoming quite popular in the open-source community, Greenscreen needed a major upgrade. Furthermore, Greenscreen was not very extensible.
After some significant refactoring, Greenscreen evolved into Stoplight…
There are a number of improvements in Stoplight. These are the most critical or useful to the end-user:
- Support for multiple (any) continuous integration server
- Highly configurable yaml files
- Cross-browser beautiful UI
- More informative build statuses
- Full test suite
Originally, I was just going to add Travis CI support to Greenscreen. However, I quickly asked myself, “why stop at Travis CI?”; we should allow developers to connect Greenscreen to any continuous integration server. After cleaning up the code a bit, I introduced the concept of a
Provider. Simply put, a
Provider is an abstract Ruby class that maps server-data into Greenscreen data. It looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
On the front-end, now we don’t have to worry about parsing different server responses; we know that any provider will respond to the
Provider#projects instance method. This makes refactoring our front-end code much easier.
Stoplight::Project clearly defines a schema and method-set that must be adhered to. In the front-end, we can simply call
.projects on any provider and know with 100% certainty that the given objects respond to a certain set of methods. Those methods are defined in the
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
This set of simple instructions tells a provider how it must format data. Essentially this makes
Provider a micro-data-mapper, massaging data from remote APIs into a standard format. Stoplight then uses that standard format to create a unified user experience.
Since Stoplight is destined to become an open-source project, it needs a comprehensive test suite. Furthermore, during our refactoring, it’s important that we don’t break existing functionality. As such, I added a full test suite with RSpec. To make development easier, I also use Spork, Guard, and Growl-Ruby to automatically run tests in the background while I’m coding. This makes TDD much more exciting.
With all those dependencies, plus running the server, it only made sense to use Foreman to manage all those processes. What used to be (in three different terminal tabs):
bundle exec shotgun -p 4567 bundle exec compass watch -c config/compass.rb bundle exec guard
bundle exec foreman start
with a tiny
1 2 3
Under the hood, all the styles for Stoplight are generated by a framework called Compass. Compass allows us to leverage the power of SCSS and easily create a cross-browser compliant application. Stoplight uses Compass and SCSS for all it’s styles. This ensures a consistent user experience.
ABAP stands for “As Big As Possible”. A tiny snippet of jQuery dynamically sizes text to fit in its bounds. Whether you’re displaying on a 60” LED TV or a 13” Monitor, the text will be as big and clear as possible.
Brace yourself for a meta-moment. Since I wanted Stoplight to become a popular open-source project, I added the build on Travis CI. With Stoplight on Travis CI we can use Stoplight to monitor the build status of Stoplight.
There you have it! What was once a very isolated and less-than-configurable tool is now highly extensible and open to contributions by the community. If you are currently using Greenscreen or another build monitoring alternative, give Stoplight a try.
I Want it!
Stoplight is available for download and forking on github. Pull requests are greatly welcome! There is also a highly-configurable chef cookbook for installing Stoplight on Apache and Passenger on your own servers.