Trying to understand what Travis CI does and when it should be used

git travis-ci git-flow
trying to figure it out picture trying to figure it out · Mar 23, 2014 · Viewed 27.9k times · Source

I am very new to Git and I am planning to contribute to some open-source project on GitHub after discovering a small error in it. Upon forking it and fixing the error, I purposed a pull request and I noticed this showing up:

Failed — The Travis CI build failed

Looking into the details I discovered it was caused by Could not find .travis.yml, which made perfect sense since I had not signed in to Travis Cl with and add .travis.yml to the repository.

This is my first time hearing about Travis and what that is known as continuous integration. And it sounds pretty cool so in order to learn more about it, I looked it up on Wikipedia.

Travis CI is a hosted, distributed continuous integration service used to build and test projects hosted at GitHub. Travis CI automatically detects when a commit has been made and pushed to a GitHub repository that is using Travis CI, and each time this happens, it will try to build the project and run tests. This includes commits to all branches, not just to the master branch.

My current understanding of Travis CI is that what it does is automatically pushing the project upon git commit -am ".." and I don't quite understand some part of it.

  1. By building the project and run tests, what tests is it going to run? And how is it going to "build" the project? (like compiling it to binary?)

  2. It states that "This includes commits to all branches" - but what if I don't want to commit to all branches?

  3. Is it alright if I don't use Travis Cl at all? Under what circumstances is it best to use it (or it must be used)?

Answer

joshua-anderson picture joshua-anderson · Mar 23, 2014

The simplest way to explain Travis CI is that it runs your program's tests every time you commit to GitHub (this can be configured in many ways, and you can always disable builds on some branches). The point of this is that you can often discover very quickly if your commit broke something, and fix it before it becomes a problem. I would recommend running Travis CI on every GitHub repo that you have unit tests in and is using a programming language supported by Travis CI. Since setting up Travis CI is very easy, I don't normally see a good reason not to use it, unless you don't care if you have passing tests in your program or not. Feel free to leave a comment if you have any more questions. You can read more about Travis CI here.

Related questions

How to find the current git branch in detached HEAD state

I can find the current git branch name by doing either of these: git branch | awk '/^\*/ { print $2 }' git describe --contains --all HEAD But when in a detached HEAD state, such as in the post build phase in a …

Read More
How to fix a permission denied (publickey) error for a git submodule update in the Github Travis CI build?

I cannot update the git submodule, with the error: $ git submodule init Submodule 'build/html' ([email protected]:quadroid/clonejs.git) registered for path 'build/html' ... $ git submodule update Cloning into 'build/html'... Warning: Permanently added 'github.com,207.97.227.239' (RSA) …

Read More
How to publish to Github Pages from Travis CI?

We are compiling Doxygen docs on the travis-ci server and want to push them onto our gh-pages branch. How do I handle the authorization for git push? Does someone have an example for using encrypted variables in travis-ci? Should I …

Read More