Until recently we’ve been handling issues with parsing .travis.yml files rather poorly. YAML is a finicky beast, and when there was a problem parsing it, we didn’t communicate that at all.

On top of that, when a project or a branch is missing, we’re still assuming the defaults and run commands focused on Ruby, which can be confusing as well.

To improve both scenarios, you will now see messages in your builds logs should we fail to parse your .travis.yml or should there be no .travis.yml available for the commit we’re currently building.

In case of a parsing issue we stop the build immediately and end it marked with an error.

We’re still improving on this front, but this at least gives a bit more transparency into why we run default commands, and we prevent your build from running with the defaults when there’s a problem with your .travis.yml.

There’s a lot of great content out there on the topic of testing, and we’d like to present some of our favorites.

From 15 hours to 15 seconds: reducing a crushing build time

A great story from the Songkick engineering team about how they cut down their testing time significantly by refocusing on what they test, and how their entire application is architected.

Using postgression on Travis CI

Dan Peterson from Heroku wrote a great article on how to use postgression, a service to get a PostgreSQL 9.2 testing instance on demand via an API, with Travis CI.

Postgression is a great service built on top of Heroku Postgres that gives you a clean Postgres instance for testing on demand.

If your project depends on PostgreSQL 9.2 in particular, this will come in handy!

Android Builds on Travis CI with Maven

The fine folks at Crowd Interactive wrote about how to setup Android projects with Maven on Travis CI.

The log output is an integral part of a build, and we’ve done quite a few iterations on how to display it in the best possible way.

The most recent addition, available on https://travis-ci.org for a while already, and now fully rolled out on https://travis-ci.com, brings a few noteworthy improvements to make it easier to pin-point problems with the build.

There’s a bigger story at play here about the logs in general, but we’ll focus on the new log viewer for now.

To start with, we made the contrast a bit easier to read, with a darker background.

More noteworthy though, we added more prominent folds, that hide common commands whose output usually isn’t relevant to the overall build, unless they fail.

We fold all commands other than the ones specified in the script section of your .travis.yml.

To make the build phase more visible in the output, they’re also nicely labeled on the righthand side.

If a folded command fails, returning a non-zero exit code, we don’t fold the section so you can immediately investigate what the problem was.