TL;DR: Secure environment variables are enabled for pull requests as long as the origin of the pull request and the target repository are the same.

Secure environment variables have been available in Travis CI for quite some time now, but there has been one thing which we always a litle annoying. Before today we were disabling secure vars for every pull request. There was of course a good reason for doing that, if we allow secure vars in a pull request an EVIL hacker could submit a pull request with the printenv command, which would display ALL of the ENV vars, including the ones, which you would like to keep secret!

The part, which was a bit annoying was the fact that some of the Pull Requests are based on a branch from the same repository. This scenario is pretty common, we use it extensively at Travis, as do many of our fantastic users. Even though I have access too all of the Travis CI repositories, I’ll submit a pull request before pushing the changes to master, not just to get feedback from our wonderful team, but also from Travis CI, which will run the build based on merge commit and marking it as passing. But if a repository needs the secure env vars to run the full test suite, it reduces the value that a PR build provides.

Today I am happy to say that this has now been fixed! I deployed a set of changes which allows for the use of secure environment variables if a pull request’s target repository is the same as the source repository. This change is available on both the open source platform and for private repositories!

These changes were sponsored by the great folks at Engine Yard, give them a big internet hug on twitter if you find this change useful!

Have an awesome week,

Piotr

Before the weekend starts off (with beautiful weather in Berlin), here are some links for you:

Four Pricing Principles To Never Forget

The Intercom team has some great advice on pricing for online businesses, where the biggest problem usually is to find the right price.

Continuous Integration for Erlang with Travis CI

Ward Bekker whipped up a great introduction on testing Erlang on Travis CI.

Using Scheme with Travis CI

Erik Holk gives us the low-down on testing Scheme (a Lisp dialect) on Travis CI.

Hey, it’s Thursday, and we just had lots of coffee! Time for a new round of links on continuous caffeine, Travis and other interesting things!

7 Ways to Refactor Fat ActiveRecord Models

Bryan from Code Climate is laying down a few excellent patterns to help you decompose ActiveRecord models that gathered a bit of weight, slowing down your tests, complecting your code base.

In my experience, adding these patterns to your workflow will not only give you a cleaner code base, but it will also help you to get a faster test suite.

NSHipster: Unit Testing

Mattt Thompson, author of AFNetworking has written a great guide on how to get set up testing Objective-C code. He has also included a section on automating test runs, outlining the steps required to get started with Objective-C on Travis CI.

Android Builds on Travis CI with Gradle

Crowd Interactive is continuing their series on doing Android builds and testing on Travis CI, this time with Gradle.

Rails Girls Summer of Code

Travis CI supports the Rails Girls Summer of Code project, which helps to get more women involved with open source. They’re currently collecting donations to make the project happen, you should consider supporting them too!