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

Ian Jenkins is a Principal Developer at Box UK. Ian works mostly with PHP, but loves trying out new things. When not sat in front of a computer, he likes to read, watch films and follow sport. Ian thinks he is the only blog contributor who does not play the guitar.

Related content

Tech round-up: Oct 14th

By Steve Anderson

Tech round-up: Aug 26th

By Steve Anderson

We're hiring. Let's talk. View available roles