For about a year or so we’ve been using Travis for Continuous Integration. It’s been brilliant and we are really happy with it. One thing that we notice from time to time though is that there can be a congestion of builds at any given time, causing a traffic jam on the build queue. With multiple devs opening multiple Pull Requests (PRs) across multiple projects it’s easy to see how this can happen. So we started to look into what we could do about it and if there were any quick wins.

Builds are triggered for every commit within a PR. This is great, and exactly what we want for new PRs or any reworking/refactoring of existing PRs. However, sometimes a PR may have a new commit where we don’t necessarily want to kick off a new build; some examples are:

  • Adding/editing documentation
  • Minor CSS changes
  • Minor Docblock changes
  • Fixing typos
  • Rebasing the branch of the PR (for example when squashing commits)

Due to the rapid feedback rate of our PRs multiple commits can get triggered with these sorts of changes in quick succession, thus causing the aforementioned blockage.

Travis had thought of this and the solution is realy simple.

Simpy add the following to the commit message and Travis will know not to trigger a build:

[ci skip]


[skip ci]

This is exactly the quick win we were after and you don’t need to add that to the initial line of the commit and pollute the history so works really well for us.

About the Author

Ian Jenkins

Ian Jenkins is a Principal Developer at Box UK. He has wide range of development experience in various platforms and languages, in particular PHP and Symfony. Ian has worked on and delivered a number of successful projects and is currently most interested in maintaining and transforming troublesome legacy projects into well-tested, high-performance web applications.