When configuring your Build Definitions on Azure Pipelines or on Azure DevOps server, you can configure a Continuous Integration (CI) build. A CI build runs for every checkin or commit that you make to source control. This allows you to start an automated process that for example compiles and deploys your build. This is a very useful process and it should be ideally setup in the above way. However there are times when you do not want the check-in to trigger a build at all.

So it make sense to avoid triggering a build when you are updating markdown files or other document related files, or may be you just updated images and some other text, which will not affect the outcome of build process at all. Normally, they should be stored as separate directories other than source code and then you can use path based filters. But what if the segregation is not setup in this way.

One easy way to avoid a CI build when you commit a change is to add ***NO_CI*** to your comment as a suffix. This signals to Azure Pipelines (and Azure DevOps) that you don’t want to run a CI build.

For example, consider below history of a git repository:

and the definition of associated CI pipeline:

In this case, since we set the trigger on master branch and are now making push to master branch with last commit message containing ***NO_CI*** flag, no build will be triggered after pushing change.

Since commits are part of the git history, you can always trace back why a certain change didn’t trigger a build.