What is a quality gate?
A quality gate is the best way to enforce a quality policy in your organization. Setting up a quality gate allows you to prevent any code that doesn't pass code reviews from being merged into certain branches.
Key Benefits
Enforce code quality consistency across the entire project
Ensure that newly committed code doesn't introduce problems
Ensure issues are addressed before being merged
Before to start
Before proceeding with creating a quality gate in your VCS for your repo, you must create a dedicated Code Reviews connection user for your project.
Enable Gating Code Reviews Settings
To automatically monitor your code with Code Reviews, you need to configure your Code Reviews Settings. You can configure your settings by navigating to the Code Reviews page, select the repository you’d like to enable gating on, then click the gear icon on the right:
In the Settings, navigate to Configuration and ensure the following settings are checked:
Enable Automated Code Reviews on PRs in tracked branches
Publish branch status checks on PRs
Publish a review on PRs in VCS
Allow Code Reviews to act as an approver on PRs
You must also have webhooks created. You can create a webhook by selecting the Create Webhook button.
If you have webhooks already created, your settings will look like this.
You can find out more information about the Code Reviews Settings on this Help Article.
Setting up Branch protection in Github
In your repository settings in GitHub, go under Settings > Branches
In the Branch protection rules section, click on Add rule classic branch protection rule
In the Branch name pattern field, type the branch name you would like to create the gate for
Suggested Setup for Branch Protection Rules
Since different organizations have different workflows, we can only provide general guidance on how to set up your branch protection rules. Below are some of the key rules that Code Reviews needs to effectively review your pull requests, which you can adjust as needed.
One essential rule is to require a pull request before merging. Enabling this rule ensures that all commits are made to a non-protected branch and submitted via a pull request before they can be merged into a protected branch. For example, if all your pull requests need to be approved by your architect, you can configure two required approvals: one from your architect and one from Code Reviews.
Another useful option is to dismiss stale pull request approvals when new commits are pushed. This means that if new commits are added to a branch that matches the rule, any existing pull request approvals will be dismissed, ensuring that new changes are reviewed before merging.
You may also want to require status checks to pass before merging. This rule allows you to specify which status checks must be completed successfully before a branch can be merged. To set this up, you need to search for the specific status check that is important to your project. Keep in mind that this is limited by GitHub’s capabilities if you do not see the desired status check, it most likely means GitHub does not currently recognize it. For example, you might want to enforce security-related checks, such as ensuring that your code is Secure, Reliable, and Compliant.
By carefully configuring these rules, you ensure that your project follows a structured and consistent quality assurance process while allowing for flexibility based on your organization's needs.