With a lot of the Version Control Systems (VCS') you can set up a particular branch protection 'rule' or 'policy' that puts in place specific enforcements for how a Pull Request (PR) must look before it can be merged.
This allows you to specify things like a minimum number of reviewers/approvals, comments being resolved, and also that particular status checks (usually external checks against the PR) must pass before you can merge that feature in.
In Azure DevOps (ADO) you can configure these as 'Branch Policies' as detailed here, and this document looks to showcase how they can be created to ensure a PR has a successful validation from a Gearset CI Job before being allowed to continue.
Policies in action:
Login to ADO, and head into Project Settings by clicking the bottom left cog icon
Click into Repositories, and you'll see a list of your available repos. Click into the one you're using in your Gearset Pipeline.
Click Policies and scroll to the bottom to find a list of your branches. Click into the branch you wish to set up a status check restriction on and this will load a new screen.
Here you can configure the right protections for that branch. In my example I've enforced a minimum number of reviewers and that comments must be resolved before we can proceed.
Scrolling down, I've also configured a 'Status Check' enforcement that a particular check must pass before we can merge the PR.
Once this is in place, you'll be able to see your branch policy in action when a PR is raised targeting that branch. We can see a couple of approvers below, alongside a 'view 2 checks' link in the overview.
Clicking into that shows us my required checks - this includes the specific external status check we flagged for the Gearset CI Job (validation succeeding) with a link that will take us to that validation, alongside the other requirement for comments to be resolved.
Note - if any status checks only get tagged onto a commit as part of a PR rather than the PR itself, ADO won't surface those into this 'checks' view, and they won't be accessible by Gearset/other tools only looking at PR-wide checks.
Inside your Gearset Pipeline, you'll be able to see any reviewers on the right hand side along with other key information on policies we can see (note: since the Gearset validation child job is already showcased in the 'Validation' section and isn't a specific ADO Pipeline, it won't show up in the 'Additional PR Checks' > 'Status Checks' section on the right hand side, but any other integrated status checks would).
Once you click 'promote changes', we try to merge that PR in ADO. If any of the required status checks aren't met due to the policies you've configured, the PR wouldn't merge and you would be shown an error message. If all the checks are successful, the PR can merge and the CI job will promote as usual.
Policies can be really powerful elements of your overall VCS configuration and help protect key elements of the Pipeline. You may wish to consider enforcing that all validations must pass as you get closer to Production, alongside an increase in number of reviewers. If you find the settings too restrictive then you can easily head back into a particular branch policy and tweak the required/optional elements accordingly to allow PRs to progress.