You're working on an important change to a GitHub project. It's a sizable change and adds a few good features. You've also been running the unit tests, integration tests, and linters frequently just like any good contributor would. Wouldn't want to break the build.

Everything comes up green!

Things are starting to shape up and you're ready to open your Pull Request. You push your changes up to your forked repository, open up a Pull Request and spend a good amount of time outlining the changes. You click Submit and watch as Travis spins up builders to run all the Continuous Integration tests when suddenly...

A red X appears in your commit status. Travis failed?

You look at the failing test and you don't understand why it's failing. It's going to be tough to see why it's failing too because everything passes on your machine. You have a few ideas though. You try each one in succession, waiting for your build to process all the way through each time. Builds sure are slow when you're watching waiting for that one issue to be reproduced.

About five attempted fixes and an hour later you finally figure it out and commit the solution to the problem, everything goes green and you're left with a Pull Request that looks something like this:

What Just Happened?

Unfortunately your Continuous Integration environment is not the same as your developer environment. This happens to be the case for a lot of Open Source projects that rely on Travis CI for Continuous Integration. Debugging becomes a nightmare the instant that something fails on Travis that you can't reproduce on your local machine.

There aren't many options, and the only ones that seem to work involve wasting a lot of resources and time by continually pushing small debugging changes until something works.

A Solution to the Problem

Because of how much I have had to deal with this myself in my own personal work on Open Source I've developed a tool called trytravis which transparently sends your git repository (along with your local changes!) to Travis and tracks the builds as they progress in the command line all without needing to commit to the actual feature branch you're working on. (Can I get a 🙌?)

Here's an asciinema recording of trytravis in action building some changes that I have made locally:

View the source for trytravis on GitHub. Licensed under Apache-2.0.

Additional Awesome Features

• The URL to your build will be displayed in the command line to allow easy access to builds without waiting for Travis CI to update which build is running.
• No breaking your workflow: all the action occurs in the command line and you only need to go to the Travis website if something goes wrong.
• Builders used by trytravis are independent of the builders for the project you're trying to commit to if you create a separate user. This means you don't have to wait forever for your jobs to build on large projects with lots of builds.
• You can configure which jobs will be built by modifying the .travis.yml file locally to pinpoint specific builds you want to focus on.

Installation and Setup

The installation and setup is a one-time undertaking. Once you've set it up once it will work with all of your projects. You can find the full details for setup and installation as well as usage documentation outlined in the README.md on GitHub. If you run into issues please don't hesitate to open up an issue on the issue tracker.

Don't forget to leave a star if you really like this project! I really appreciate it. ✨

Find Me on Twitter

I have a Twitter where I post about stuff that's important to me like Python, virtualization, and distributed computing. You can follow me if this tool or those topics interest you.

Thanks for reading! ✨🍰✨