Coninuous Integration with Travis ci


One of the open issues with our ZipShare project was to integrate some sort of continuous integration into the project. Basically, what it does is automatically build your project on a remote CI server. If there are any errors or conflicts the build will fail and will have to be fixed before resubmitting.

Since we’re going to be using travis-ci for our team project I chose that to mess around with on one of my own projects. However, there seem to be quite a few hosted CI services. I actually had only heard of travis-ci before digging into this deeper. On to my problems.

The initial setup is super easy, basically all you do is login to the travis-ci site through github and it will sync with your repositories. Once this is complete, you can go into your settings and and flip the “switch” to “on” for whichever repository you choose.

Once that is complete, all you need to do is add a .travis.yml file to the root of your project and push to github. This will automatically trigger a new build with the “default” build settings. You may have to go into the repository settings on github and on the left you’ll see a “Webhooks & Services” once you click that under “services” click the “Travis CI” and in the header you’ll see a “test service” button. To get my first build going I had to manually go in and perform those tasks.

You’ll probably want to go in and configure your .travis.yml file with ruby version, database etc. The nice thing is you can add script lines that will run tests or linters for you. This is great because if you have failing tests your build won’t pass. Anyway, after some playing around and a bunch of pushes to github I got my build failing because rubocop was for some reason running on over 5000 files…oops.

Screenshot

The cool thing with travis is it lets you see what’s going on in the build. It’s just like if you were setting up a project on your local machine. I went through the travis logs for a while trying to figure out why my cops were scanning every file when in development they don’t…

Finally, I came across this line in the travis log.

$ bundle install --jobs=3 --retry=3 --deployment

Running bundle help install locally I noticed that the --deployment flag creates a directory vendor/bundle and installs the gems. Since my .rubocop.yml didn’t exclude that directoy it was actually scanning all those library’s. Here’s my updated .travis.yml and .rubocop.yml.

Screenshot

You can see from that file, I have travis run my linter along with specs. What I like best about the whole process is it will automatically build pull-requests. Here it’s doing just that:

Screenshot Screenshot

Given that I typically submit pull requests to master this will build everything and give me the “green light” that it’s okay to merge. Yay!

Almost forgot, while I was searching for a fix to the bug, I encountered this:

Screenshot

Unfortunately, I can’t take credit but thought it was pretty funny, they seem to have ran into the same issue I did. Till next time.

comments powered by Disqus