After setting up your build definition and running your first builds, you might also see the first failures coming in—for example, when someone accidentally commits and pushes changes that do not compile or contain unit tests that do not run successfully. You can prevent this by having a build definition run automatically whenever a pull request comes in. To configure this, go through the following steps:

1. Click on Policies under Project Settings. The following screen will open. Click on Add build policy:

2. Select a build definition that you want to use to validate the pull request.
3. Next, there will be three more things that you can configure:
   • Trigger: When the build definition should start, either automatically or manually. Of course, the real value comes from running a verification build automatically.
   • Policy requirement: This determines whether a pull request can be completed if the build fails. In other words, this determines whether you can ignore a failing build. It is recommended that you avoid setting this to Optional, if possible.
   • Build expiration: This determines how long a positive build result is valid for. The default value is 12 hours, but you should consider changing this to Immediately when master is updated. The advantage of this is that you cannot merge changes without first running the build against a combination of the current state of the branch that you will merge to and the proposed changes.

You can add more than one build policy. If you have a lot of things that you can automatically validate and want to keep automated validation times to a minimum, then this is a good approach.