- Feature: Build matrices
It is now possible to expand builds to build matrices, e.g. for testing against various Rubies, Gemfiles or env var settings.
The .travis.yml file now takes “rvm”, “gemfile” and “env” as known configuration keys. “script” remains unchanged. Here’s an example: https://gist.github.com/883181 This would create a build matrix with 3 dimensions (rvm, gemfile, env) and 2 values each, resulting in 6 builds total. E.g. the first build would be run with `rvm use 1.8.7; FOO=bar BUNDLE_GEMFILE=test/gemfiles/rails-2.3.x rake ci`
- Refactoring: The client-side backbone.js has been massively refactored.
Amongst other changes it now only loads the required json data for builds (previously it loaded all builds for a given repository on all repository views).
- Refactoring: The Jammit integration should now work the same way as the Compass integration.
I.e. it jammits on demand on the first request, puts the resulting asset to the local tmp directory and sends it to the client. From now on Varnish should cache it so it doesn’t matter if the tmp directory gets killed.
- Feature: Websocket messages are synchronized client-side
Previously messages came in in a somewhat random order depending on latency etc. That messed up build logs quite a bit. Messages now have a msg_id which is incremented with each message. This allows us to re-synchronize messages on the client-side and then process them in the correct order.
- Feature: Log folding
Previously one had to scroll down a lot to find the actual test output because on a repository like travis-ci/travis-ci the log contains quite some output from `bundle install` and `rake db:migrate`. These log sections are now folded so that only the first line is displayed in the log and one can click to expand this fold.
- Refactoring: “Everything through the app”
Previously workers directly POSTed messages to Pusher.app and also POSTed to the app. We agreed to change this architecture so that workers would only POST to the app which, in turn, will then POST to Pusher. This change also made it necessary to synchronize messages in the app, too. It seems that messages arrive much slower at the client when they’re processed by the app first and then forwarded to Pusher.app. It’s unclear whether we’re pushing too many messages and should introduce a buffer in the worker that would buffer messages for like 500 ms and only then POST them to the app.
- Feature: E-Mail notifications for repo owners, build committer and author
Previously Travis only sent email notifications to the committer’s email as passed by Github as part of the service hook payload. Travis now fetches the current repository owner’s email address from the Github API. If the repository is owned by an organization then the organization’s public member’s email addresses are fetched. Travis will then sent build notifications to the following email addresses: repo owner(s), build author, build committer. In future we will also add a config option to the .travis.yml file to overwrite these recipients.
- Refactoring: leaner JSON data
With the “everything through the app” change the various JSON hashes that are pushed around with various messages were trimmed down quite a bit.
- Refactoring: denormalize last_build data to repositories
Repositories now have their last build data (i.e. attributes such as last_build_id, last_build_status etc.) denormalized. This allowed to simplify quite some portions of the app and client-side js code.
- Feature: It should publish the currently deployed Git commit sha as an HTTP header (but it doesn’t)
See http://blog.andrewvc.com/making-life-easier-with-git-shas-in-your-http and https://github.com/travis-ci/travis-ci/commit/1e3d1d2017ca7498ea745c91b26e8c991c8aee04 as well as https://github.com/travis-ci/travis-ci/commit/e3fa3993d245b513691eb1f445e1f7a2d28de5ab, but also: `curl -I http://travis-ci.org`. Apparently it doesn’t work.