Skipping a CI Build for non-code changes

Skipping a CI Build for non-code changes

Table Of Contents

Skipping a CI build is like purposefully not brushing your teeth every morning and evening. You know it should not be skipped and you feel guilty when you do it anyways. However, there are some cases when you have only changed some supplementary files (like documentation) that have no impact whatsoever on your build pipeline and you don’t want to wait for a long-running build. Here are two ways how to skip a CI build in this case.

Using the Commit Message [skip ci]

The easiest way to skip a CI build is to add [skip ci] or [ci skip] to your commit message. Many CI providers support this:

This solution has two major drawbacks, though.

Firstly, it pollutes the git commit messages with meta information that is only relevant to the CI system and brings no value to the commit history.

Secondly, the above commit message will cause the CI system to ignore the push / pull request completely, i.e. it will not even register in your CI history. This will cause any hooks you have installed to your build pipeline not to run.

You’re screwed, for example, if you have protected the branches of your GitHub repository, so that pull requests can only be merged when the CI build for the pull request has successfully run. This will never happen using [skip ci], so you can never merge the pull request… .

Using a Git Diff in the CI Build

So, we actually want the CI build to start - only to immediately exit when only non-code changes were made.

I’ve found a nice script for Travis CI on GitHub and modified it a little:

if ! git diff --name-only $TRAVIS_COMMIT_RANGE | grep -qvE '(.md$)'
then
  echo "Only docs were updated, not running the CI."
  exit
fi

This script creates a diff of all commits within the $TRAVIS_COMMIT_RANGE (i.e. within the current push or pull request) and exits the build if it only includes markdown files (*.md). We could modify the regular expression to include more than just markdown files. It can be included into a build, like I did in my code examples repository.

However, of the big CI providers, only Travis CI currently supports the necessary “commit range” environment variable:

A Word of Caution

Use wisely and with caution. The build should never be skipped when a file changed that has any impact on the build. So, if your markdown files are part of your build, don’t skip the build.

Written By:

Tom Hombergs

Written By:

Tom Hombergs

As a professional software engineer, consultant, architect, general problem solver, I've been practicing the software craft for more than fifteen years and I'm still learning something new every day. I love sharing the things I learned, so you (and future me) can get a head start. That's why I founded reflectoring.io.

Recent Posts

Demystifying Transactions and Exceptions with Spring

One of the most convincing justifications for using the Spring Framework is its extensive transaction support. For transaction management, the Spring Framework offers a stable abstraction.

Read more

JUnit 5 Parameterized Tests

If you’re reading this article, it means you’re already well-versed with JUnit. Let me give you a summary of JUnit - In software development, we developers write code which does something simple as designing a person’s profile or as complex as making a payment (in a banking system).

Read more

Building a CSV Importer with Node.js

Consider the case where someone provides us with a CSV file containing employee details that have been exported from an employee management application.

Read more