Happy Holidays builders! Today let’s debug. We’ll be talking about Dockerfiles, and how we can trigger those in our crafty
.travis.yml files. Let’s get started!
Now 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, so in turn let Docker know what image you are using on Travis CI.
- Make up your own temporary build ID:
- View the build log, open the show more button for
WORKER INFORMATIONand find the
- Then run the headless server:
docker run --name $BUILDID -dit $INSTANCE /sbin/init
- Run the attached client:
docker exec -it $BUILDID bash -l
Now you are now inside your Travis environment. Run
su - travis to begin:
Remember to run your build in Debug mode, you can also do this in the GUI:
If you’re using something like
npm don’t forget to make sure that the step in question doesn’t completely crash the Docker build by returning a non-error exit code, e.g. in case the npm run build step in the Dockerfile fails:
RUN npm run build; exit 0
Classically you were able to solve this usually by adding:
Annotations are allowed in Docker for the reason of defining architecture and operating system (overriding the image’s current values), os features, and an architecture variant, this takes precedent over env vars in the Docker protocol heirarchy. An example of using annotation would look something like:
docker manifest annotate 00.00.00.000:5000/debug-test:v1 00.00.00.00:5000/
Now let’s run your Dockerfile!
docker run — rm -it (image name)
There you have it! You’ve just debugged a Docker image in Travis CI!
As always remember if you have any questions, any questions at all, please email me at firstname.lastname@example.org.
Happy building and Happy Holidays!