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

Question

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 CI. 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 1

1. Whatever tests are part of the overall project. Unit tests and integration tests are part of some projects that are supposed to run after code changes are done to ensure that functionality still works as originally intended. Failed tests may have to be changed or there may be bugs that were missed in the initial code change. There is likely some kind of makefile in the project that is used to compile the project into whatever end form it has,e.g. an executable, DLL, website or other component.

2. While there may be an option to change this somewhere, it may be that the changes are intended to go into all future releases and thus the commit should be reflected in all the branches outstanding I'd think.

3. That may depend on who runs the project as the general idea of CI is to check that a commit doesn't break the software or tests. Consider the case that if you commit code with typos that doesn't compile. This is generally bad and a CI server will catch this quickly so that it can be fixed. Similarly, there may be regression tests that aren't usually run that a CI server may catch when developers commit their changes. Some people believe in the idea that commits shouldn't break the build ever and so only commit once things are working while others believe in one often committing changes whether it breaks the build or not. When to commit code has various answers that may be useful on this point.