Git makes it very easy to create and merge branches around new features and bug fixes. Entire workflows sparked around the ease of branching off with Git. Whichever approach you use, Travis loves all your branches equally and builds them happily as you push them.

Pull requests have changed that workflow for a lot of users though. While new features still evolve around separate branches created off a master, production or development branch, or even your own fork, they start out early as a pull requests.

Opening a pull request early allows discussions around what the end result looks like. They also make community or internal code review a breeze. GitHub themselves have popularized this workflow and it has been adapted by numerous other companies and teams, the Travis team included. Heck, even this blog post was written on a branch and submitted for review via pull request. This little button on GitHub makes it so easy:

We love pull requests a lot. So does Travisbot, who leaves a totally un-opinionated comment on pull requests to let the owner know if they passed or failed.

With the availability of pull requests for everyone, including private repositories on Travis Pro, you can now easily choose your workflow and bend Travis to your own needs. You can either choose to keep building all branches (which is the default).

Or, as some of our early Travis Pro customers have started doing, you can choose to only have Travis build pull requests and a number of important branches that are relevant to shipping code (master, production, development, staging, etc.) For one thing, because it fits their workflow better. The other upshot is that Travis doesn’t build the same commits twice.

We get notified when you push to a feature branch and when the corresponding pull request is updated with these commits. Restricting the number of branches on Travis makes sure you don’t build the same commits more than once as you keep working on a feature. They’ll only be build again when merged into your shipping branch.

To restrict Travis to only build a small set of branches, you can add a section to you .travis.yml file:

branches:
  only:
    - master
    - production
    - staging

The added benefit of using this approach is that the build status becomes a part of the code history as it evolves, making it visual (by way of comments on the pull requests), which commits caused problems and which ones kept the code in a shippable state.

Two months ago we announced support for Pull Request testing. Since then, you’ve managed to keep The Travis Bot quite busy.

We just started unrolling an updated version and are in the process of turning it on for everybody.

Private Projects

Up until now, Pull Request testing was only available for Open Source projects. We had to make some adjustments to Travis CI and are proud to announce the availability for private projects.

We enabled the feature for all repositories already set up on “Travis Pro”. Please swing by our support channel if you are having issues.

If you want to see our bot leave comments on your Pull Requests, you will have to give travisbot read access to the repository. Otherwise you will have to check the Pull Request tab in the Travis CI interface.

A new way of communicating the outcome is in the makings, stay tuned.

Pull Requests for Branches

We found that especially for private or large projects, Pull Requests often come from a different branch within the same repository. You might be wondering what advantage Pull Request testing actually gives you in this scenario. Branches are already being tested for you, so what’s the difference?

Keep in mind that a Pull Request test will actually reflect the status of the merged Pull Request. Imagine working on a feature branch for a while and in the meantime, master gets updated. A Pull Request test will now reflect the state after you’ve pressed the Merge Button. This is also why only mergeable Pull Requests will be tested.

Open Source Projects

After getting participants of our Love Campaign on board, we will now start enabling it for the rest of the nearly 18k Open Source projects using Travis CI. Current plans are to enable it in batches, probably on the scale of 500 to 1000 repositories per batch, so we can see how much more load this will cause. The first batch will be enabled tomorrow and we plan to enable one more batch every morning.

New projects will be enabled automatically.

No More Race Condition

Our initial release had a high level race condition. Basically, if your project was too busy, you could see a failing test with an error message like this:

$ git checkout -qf 8ad4fb8f248e00c8e86c
fatal: reference is not a tree: 8ad4fb8f248e00c8e86c

That happened mostly if a merge commit changed due to the base branch being updated while some but not all of your build’s jobs already ran. We started deploying the fix to our worker machines and within 24 hours the fix should be available on all machines. If you want to know more, we invite you to read the full story.

Thanks for all your support. Without your help we would not have been able to get this feature out of the door for everyone.

The Travis Team

Until recently, we only synchronized your GitHub repositories once, when you first created your account on Travis. That had the downside that when you created new repositories they wouldn’t automatically show up, and you had to set up the build hook manually.

We also didn’t show you the organization repositories you have access to. So again, there had to be a manual set up process to get the project running on Travis.

Also, in the rare case that you renamed your GitHub account (just as I did recently) we wouldn’t pick up that change.

Keeping Your Repositories in Sync

Thankfully, all this is now in the past, and as of recently, we introduced a synchronizing step in Travis that allows you to keep your profile and list of repositories up to date.

When you log in for the first time we trigger a background task that checks with GitHub and fetches all the repositories you have administrative access to. Why only administrative? Only administrators of a repository are allowed to configure the service hook required for Travis.

So when you log in and go to your profile page for the first time, you’ll be greeted with this screen. To show you how serious this synchronizing process is, notice the progress indicator.

You can leave the page open until the process is finish, your repositories will automatically show up once it’s done.

You can trigger a sync when you added a new repository. We also trigger one every time you log in, to make sure we’re already up-to-date should you want to set up a new repository right away.

My Repositories

One more thing…

Until now, the “My Repositories” tab used to be a pretty lonely place. It only showed your personal repositories Travis knows about, not the ones of your organizations.

To make it a merrier place for everyone it now shows all the repositories that we synced for you, so all repositories you have access to now show up in that tab, nicely sorted by the most recent build, including all the repositories of organizations you’re a member of. That way, when a new user signs up and his or her organization is already using Travis, he or she will have immediate access to the respective repositories.

This is much less confusing for everyone using Travis. There is still a tiny bug in our synchronization which we’re currently working on. Currently you’ll only see repositories you have administrative rights too, basically the same as in your profile page. We’re improving the synchronization to respect push access too, so that you’ll see all repositories you have push access too as well.

On Travis Pro…

All this is relevant to Travis Pro as well, to go full circle on this. A user that has administrator access to repos of several organizations on GitHub should be able to have access to all of them on Travis as well. This change benefits both platforms as it’s now much much easier to set up Travis CI for public and private repositories as needed.