How to run travis-ci locally
Travis-ci offers a new container-based infrastructure that uses docker. This can be very useful if you're trying to troubleshoot a travis-ci build by reproducing it locally. This is taken from Travis CI's documentation.
Troubleshooting Locally in a Docker Image
If you're having trouble tracking down the exact problem in a build it often helps to run the build locally. To do this you need to be using our container based infrastructure (ie, have sudo: false
in your .travis.yml
), and to know which Docker image you are using on Travis CI.
Running a Container Based Docker Image Locally
- Download and install the Docker Engine.
Select an image from Docker Hub. If you're not using a language-specific image pick
ci-ruby
. Open a terminal and start an interactive Docker session using the image URL:docker run -it travisci/ubuntu-ruby:18.04 /bin/bash
Switch to the
travis
user:su - travis
- Clone your git repository into the
/
folder of the image. - Manually install any dependencies.
- Manually run your Travis CI build command.
This process allows you to completely reproduce any Travis build job on your computer. Also, you can interrupt the process at any time and debug. Below is an example where I perfectly reproduce the results of job #191.1 on php-school/cli-menu .
Prerequisites
- You have public repo on GitHub
- You ran at least one build on Travis
- You have Docker set up on your computer
Set up the build environment
Reference: https://docs.travis-ci.com/user/common-build-problems/
Make up your own temporary build ID
BUILDID="build-$RANDOM"
View the build log, open the show more button for WORKER INFORMATION and find the INSTANCE line, paste it in here and run (replace the tag after the colon with the newest available one):
INSTANCE="travisci/ci-garnet:packer-1512502276-986baf0"
Run the headless server
docker run --name $BUILDID -dit $INSTANCE /sbin/init
Run the attached client
docker exec -it $BUILDID bash -l
Run the job
Now you are now inside your Travis environment. Run su - travis
to begin.
This step is well defined but it is more tedious and manual. You will find every command that Travis runs in the environment. To do this, look for for everything in the right column which has a tag like 0.03s.
On the left side you will see the actual commands. Run those commands, in order.
Result
Now is a good time to run the history
command. You can restart the process and replay those commands to run the same test against an updated code base.
- If your repo is private:
ssh-keygen -t rsa -b 4096 -C "YOUR EMAIL REGISTERED IN GITHUB"
thencat ~/.ssh/id_rsa.pub
and click here to add a key - FYI: you can
git pull
from inside docker to load commits from your dev box before you push them to GitHub - If you want to change the commands Travis runs then it is YOUR responsibility to figure out how that translates back into a working
.travis.yml
. - I don't know how to clean up the Docker environment, it looks complicated, maybe this leaks memory
UPDATE: I now have a complete turnkey, all-in-one answer, see https://stackoverflow.com/a/49019950/300224. Only took 3 years to figure out!
According to the Travis documentation: https://github.com/travis-ci/travis-ci there is a concoction of projects that collude to deliver the Travis CI web service we know and love. The following subset of projects appears to allow local make test
functionality using the .travis.yml
in your project:
travis-build
travis-build creates the build
script for each job. It takes the configuration from the .travis.yml
file and
creates a bash
script that is then run in the build environment by
travis-worker.
travis-cookbooks
travis-cookbooks holds the Chef cookbooks that are used to provision the build environments.
travis-worker
travis-worker is responsible for running the build scripts in a clean environment. It streams the log output to travis-logs and pushes state updates (build starting/finishing) to travis-hub.
(The other subprojects are responsible for communicating with GitHub, their web interface, email, and their API.)