I was recently working on a Gem I created called Toolshed. The purpose of this tool is to turn everyday tasks into automated ones. At least to a certain degree. This will allow you more time to do the heavy lifting tasks. For example some of the functionality that this tool provides is creating a Github pull request, updating Pivotal ticket status as well as many Git more tasks. All of this would normally require you to go up into the sites interface click around and enter the data. As we all know that takes time and time is valuable. So down to the part that I had trouble with when I was creating tests for this tool.

I first started to create all of the tests locally and verify that they worked there. I had no trouble with this and everything appeared to be working. I was not getting any test failures. After creating a couple of them I wanted to see if I could get it working up on Travis CI. Travis works well with a ruby project plus since the Gem is open source it’s free. So I setup Travis and everything seemed to be working right. The first couple of runs seemed to pass without issue. Over the next few days I noticed that Travis was failing randomly. I would push up a small change and it would fail. I would run it again and it would pass using the same code base. It seemed random and a CI that has random failures is useless. The theory behind that is if errors happening randomly there they will also happen within your application. So I needed to investigate this further. Since I was unable to recreate the issues on my local machine I decided to try it out on a different machine. I created an ubuntu environment and started fresh. Once I got to that environment I was able to reproduce the problems I was having on Travis pretty easily. I was able to debug real time which helps instead of pushing new commits up to Travis.

What I noticed was that my Git commands were not finishing before it started the next one. So it would be doing a git remote update and then the next command would run before that finished. This would cause it to fail because it depend on remote update finishing first. So I had to create a solution for this and here is that solution.

until (system("git remote update"))
  sleep 1
end

This will sleep and wait until it hears a response. This will now wait for each command to run in it’s specific order. I have now tested it out several times on Travis and am no longer having this issue.