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
trytravisare 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.ymlfile 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! ✨ðŸ°âœ¨
Top comments (5)
Wouldn't it be better to use Docker so that the build is reproducible everywhere, rather than using an app that's specific to Travis? That way, the dev environment is the same as the CI environment. Not sure how good Travis' Docker support is, but on CircleCI you can use any Docker image you like. Using Docker also means you don't have to reinstall dependencies for every single build.
If you can afford to use CircleCI then you don't have those problems. Just given how many Free-Tier builds that Travis CI processes every year I'd say that the vast majority of the Open Source community can't afford CircleCI.
Travis supports using Docker during builds but doesn't support running pre-defined Dockerfiles.
Forgive me if I'm wrong (I haven't used Docker at all) but doesn't Docker inherit your current operating system? If that's the case then you'd also require being on the same platform which isn't feasible.
I'd also say that Docker isn't built for Windows <10 or Mac OS yet, so if you're on those platforms you don't have access to Docker builds locally.
CircleCI have a free version for open-source projects. We use it for Yarn. It's faster than Travis, more reliable, more customizable, has the ability to archive build artifacts, and they have some more advanced debugging features like the ability to SSH into the build box (which is fantastic for inspecting the environment when the build fails). We do the main builds on CircleCI, and only some auxiliary builds that are okay to be a bit slower (like testing on older Node.js versions) on Travis.
Docker images are self-contained. It doesn't matter if you're on Windows, Linux, or MacOS, the Docker image will function exactly the same way. The Docker image contains the OS for your build, along with all the other dependencies. For example, there's a Node.js Docker image that contains Debian Linux (or Alpine Linux) + Node.js. If you use that Docker image, you will always be using Debian Linux + Node.js, regardless of whether you're running the image on Windows, MacOS, or Linux. If you need some additional tools, you can make your own Dockerfile that inherits from another one, and run some extra commands (like apt-get to install more programs).
This also means that your CI environment will be exactly identical to your dev environment, if you use the same Docker image in both.
Docker is available for MacOS. Agree that it's only available on Windows 10, but most Windows devs I know are on Windows 10. There's very very few that are still on Windows 8, and even fewer that are still on Vista.
Developers don't have to use the Docker image, but is really helps in ensuring a consistent environment across dev, CI, and prod.
Uhm. Never heard of
git commit --amend,git rebase -iand/orgit push -f?Just fixup your commit/branch using these, then force-push the (topic-)branch and Travis happily builds again. Repeat until satisfied. No need for any custom scripting at all.
Hi Seth,
Thanks for sharing your knowledge. I'm working on running your tool inside a custom Docker container so that changes all tested locally before pushing upstream to the TravisCI site for the build to pass.
Kudos!