Travis “Continuous” Integration
There might be a need to update the contents of a website at certain intervals of time. I exploited Travis CI to serve my purpose for a website hosted on GitHub pages, automatically.
Continuous Integration is the practice of merging small patches to the shared mainline frequently. This practice is more common compared to merging in a massive change at the end of a development cycle as it is believed to prevent integration problems. But along with that, it becomes the responsibility of the developer to test every small change they make, which might make continuous integration intimidating. To address such issues the concept of build servers were introduced, which would perform the tests automatically as soon as a new change was proposed. This makes sure the changes introduced do not bring in new bugs. By and by, as it became common to host programs online, there was a need to have such build servers on the internet. Travis CI is one such service which provides distributed continuous integration service and is used to build and test programs hosted at GitHub. It is the most popular continuous integration service and provides support for both Linux and Mac environments.
Travis CI provides a lot of options regarding when to test code. It can be set up to check the code on any branch of a repository as soon as a commit is pushed, or automatically from time to time. I exploited this feature of Travis CI to update the contents of a website hosted using GitHub pages automatically.
In situations such as updating status, or updating some counter, or updating feeds, where one needs to update the website only after a certain amount of time, using this hack might be handy. Moreover, it helps to avoid the costs of hosting the stuff on a paid server for a task as simple as this.
I made use of the fact that a commit triggers Travis CI to execute tests. If the test script can be designed in a way that it does the necessary updates and pushes another commit just before it completes, Travis CI will be triggered again to conduct the tests, and this process goes on and on.
Procedure
.travis.yml is the script which conducts the test, and its syntax is well explained in the Travis CI docs. We have a script git_config.sh which sets all the necessary settings in git. deploy.sh is our built script where the necessary update is carried out. Finally, push.sh is used to create a commit and push to GitHub.
Here, language is set to bash. One may feel free to choose any language as per requirement. First, we configure git branches and switch it to master.
One needs to generate a personal access token, referred to as the OUATH_KEY here, from the GitHub website. If you are logged in, you can create it here. This needs to be placed as environment variables in the Travis CI settings for that particular repository. The settings page would be available at https://travis-ci.org/<GitHub handle>/<repository name>/settings
We create a new remote in git with the OUATH_KEY in the URL so that we have permission to push to it. We fetch from it and checkout to the remote origin. The deploy.sh contains the scripts to update the contents (or whatever is desired). For testing purpose, one may merely make the script create a text file with randomly generated string to make sure there is always a diff, and we can successfully make a commit.
The next step is interesting as well. Travis CI does a shallow clone of a repository, which comprises only up to 50 previous commits. We unshallow it, for, if not done, one may not be able to force push. Force pushing is needed so that the repository does not get cluttered with commits. We delete the existing deployment branch (here known as “gh-pages”) and create a new one. We checkout to it from the master branch and make a commit on top of it. This makes sure that the deployment branch is just one commit ahead of the master and that any changes made to the master would get incorporated in the deployment branch at the next build.
In the next step, we configure git with username and email. It is recommended to use a fake email and username (or one with which no GitHub account exists) to avoid an explosion in the contribution chart. The commit is impressive as well. Other than the files to be deployed, we add a file hist.txt to the staging area. This is the file that contains a randomly generated string and is created everytime deploy.sh runs, as mentioned before. This makes sure that even if there’s no update of status, the commit occurs. It is crucial for the commit to occur. Otherwise, the Travis won’t be triggered again. Next, we force push the files.
Please note that this is to be used only in cases in which reliability is not an issue, as Travis CI often suffers network problems, and builds can fail. I have seen builds failing at least once in two months. Restarting the build generally fixes the issue. Nevertheless, Travis CI has a cron system which makes sure that even if a build fails, it’s restarted automatically once in the next 24 hours.
Example usage of this system can be seen in the MetaKGP Naarad site, which is updated roughly every 30 minutes using this method. The repository is hosted here. This is the link to the corresponding Travis CI page.
Hope you found this post helpful!
