Background
Some time back I created an Ansible playbook to install software and setup my Mac Book Pro. I put the code for this on GitHub. I wanted the ability to keep running this playbook but without really having to test it on my mac every time. This is when I came across Travis CI. It is continuous integration server which helps to test and deploy the code with confidence. The best part is it is completely free for open source projects. I setup the build to run whenever there is any change to my GitHub repository. There is also a daily build which runs as a cron job. Setting up the CI build is very simple and integrates nicely with GitHub.
The breaking build
The builds were running successfully for past few weeks. Recently there was a failure reported by Travis CI after executing the automatically scheduled build. I had not changed anything in code for few days. So it was surprising to see a broken build. There are cases when Travis CI build fails due to timeout issues. These occur when the playbook tries to install Java or IntelliJ ide IDE. These are my known issues and they get resolved when the build is trigged again. I thought it was one of those timeout issues and restarted the build. Unfortunately it did not resolve the build failure.
The build failure was caused by one of the task within the Ansible playbook. The task tries to install a Visual Studio Code extension named vscode-yaml-validation. Below is the screenshot of the Travis CI build output log
This particular extension has been unpublished from the VS Code Marketplace. When you go to the Marketplace, you get an info message which says “This extension is now unpublished from Marketplace. You can choose to uninstall it”. If I did not have the Travis CI build running, it would have been difficult to identify that this extension is no longer available in marketplace.
When the Ansible playbook runs, it only checks if the extension is not installed and installs it. The step would be ignored on my Mac as I already have the extension installed. This is where Travis CI shines. It allows me to run the setup everytime on a new Mac whenever the build is triggered. It is as if running the setup playbook for the first time.
The fix is quite simple for this unpublished extension. I need to remove it from the list of my VS code extensions in the Ansible setup. This should be available shortly on GitHub repo.
Conclusion
I have found Travis CI very useful. It allows me to test the Ansible playbook on the remote infrastructure. I do not have to test the changes on my main Mac. It also acts a automatic regression tool. One of my favorite feature of Travis CI is its ability to support multiple operating systems and multiple versions of dependencies. For one of the repository where I contribute to the Ansible role, we are targeting multiple versions of Ansible 2.0.2 and 2.3.0. We can parameterize the build to run with each of those versions of Ansible. The builds run in parallel and can greatly reduce the amount of time required to find any breaking changes due to recent commits. This allows us to build like a matrix of different operating system and the specific versions of libraries or dependencies. Below is a screenshot of multiple versions of Ansible that I talked about
I intend to enable continuous integration for all my active projects hosted on GitHub. Since it is free I would also recommend you to make good use of it especially if you have projects on GitHub. I am not aware of any free hosting environment which allows you to provision a machine with Mac OS installed on it. That is one of the biggest distinguishing factor personally for me to chose Travis CI.
