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.
Simpy add the following to the commit message and Travis will know not to trigger a build:
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.
If you want to stay up-to-date with the events, articles and tools that have excited our dev community, take a look at our regular tech round-up series, published weekly - and sign up to our mailing list to have them delivered direct to your inbox.