Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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)?

share|improve this question

1 Answer 1

up vote 0 down vote accepted

Welcome to SQA, I think you've got a few questions going on, so I'll try and answer them in sections.

Whats Travis/Continous Integration

Travis-CI is one of a number of build automation tools that help developers understand if their application is working by building, testing and reporting on the build sequences the developer has configured. Frequently these tools are described as being Continuous Integration tools, though how accurate this label is depends on the configuration you've set up.

The Continous part reflects the fact that these tools will detect, either by polling (Checking every n minutes), hooks (Your version control system contacts the tool to say a change has happened) or by simple timers (Rebuild every hour). When a build occurs the tool will take the source code and run the configured build and report upon the stability of the project, for example "Compile error", "1/123 tests failed", "10% slower response time to previous builds" etc

The "Integration" part reflects the fact that modern software development often requires the interaction between multiple separate components working together smoothly. In a CI system you will often find that the tool will retrieve the latest release or development version (depending on your own configuration needs) and compiles, tests, ( possibly deploying somewhere along the way) to ensure your changes not only work within itself, but also work with other systems that it depends upon which may have changed.

Travis-CI is a cloud based service offered to OpenSource projects hosted on GitHub and rather than demanding a job is configured in a database on their platform you describe the parameters of your build sequence using the .travis.yml file.

Other CI providers/tools include Jenkins, Bamboo, TeamCity, Circle-CI, and many more.

How/What does it do?

When you forked the public project, GitHub also forked a number of internal configuration settings including hooks to Travis-CI. This means that when you make your changes and push your code to github using git push [origin [branch]] GitHub will contact travis-ci to trigger a new build.

Travis-CI will, given a path and revision id, clone the repository and build the code as described in that .travis.yml file. The build configuration itself can become quite complicated, so i'd suggest having a read of the Configuring your build documentation and compare it to the file you've got in your repository.

Your actual questions

  1. The tests that are run are probably the same tests you should be running during development, but check that .travis.yml for the specifics
  2. Travis-CI will only be building changes to branches, if you only commit and push changes to a branch named feature-Tobys-Branch then Travis will get told this by GitHub and only build that one branch.
  3. This depends on the project maintainer. Its not a requirement to use travis-ci but it helps the owner of the original project know if your changes have introduced any problems before they accept the merge into their project. It acts as a form of "canary" for the team.
share|improve this answer
    
Thank you so much for teaching me about CI, Travis and project workflow in such great details! It is very insightful! Greatly appreciate! –  trying to figure it out Mar 26 at 13:34
    
No problem, I'm glad I could help. –  Toby Jackson Mar 26 at 15:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.