By default, all pull requests which are validated by Gearset go through a minimum level of automatic testing, which is Salesforce validation. Any change that you are attempting to introduce into your Pipeline will need to be validated against the org you'd like to deploy it to, to make sure it's functional.

You can add extra layers to this integrated testing, in the settings of the CI jobs that make up your pipeline.

Configure the level of unit testing you would like to run on the code that you've included in your pull request, and the org that you're deploying it to. we have more information on what these testing levels mean here.

If the pull request does not pass the specified level of testing then it remains as a pull request and cannot be merged until these issues are resolved.

Try the 'run only the changes in my package' if you'd like to run tests only on any new code you're introducing rather than any legacy code that may be in your org and slow you down.

Gearset supports the creation of customized static code analysis rulesets (learn how to create one here ) and you can use these to make sure that if specific rules are violated then the promotion of a pull request will be blocked. Gearset will run static code analysis over the proposed change and produce a report on the code quality of the pull request. If the code quality violates the rules configured in that CI jobs settings then the change cannot be promoted.

Try monitoring jobs if you'd like to see the static code analysis report of an entire org at once.

This is a piece of integrated testing which can only be found in the Pipelines and CI part of Gearset, and allows you to integrate the testing of your LWC into your Pipeline. Depending on the settings you configure you can prevent a pull request being promoted if the lightning web components within that pull request do not pass their tests.

There are many ways to incorporate code review into your Gearset Pipeline - you might want to integrate Jira and your internal comms channel and tag a teammate in a ticket update. You might also want to follow the more traditional path and do your code review on the pull request itself.

This is where we see one of the advantages of connecting Gearset with your businesses chosen source control provider. If the business already has a minimum standard of code review or protected branches then Gearset will respect that.

You may want to set up some new rules for your Pipeline to make sure that your teammates are viewing and approving any changes that you're making. Depending on your source control provider these may be called branch rules or branch policies.

In Azure these are called branch policies.

The promotion of the change will now be blocked until at least one other person has approved it.

In GitHub these are called branch protection rules.

The promotion of the change will now be blocked until at least one other person has approved it.

With these settings checked, the Promote Changes button will still show against your PR's in the Pipeline, but will not let them be merged and show this message if the Review has not been completed

If you are a Repo Admin; to see the same behavior in Pipelines, make sure the following setting is checked

In GitLab you can protect branches, which means that only limited groups are able to directly push code.

Merge requests are required before being able to push code to this branch.

In Bitbucket you can set up Branch permissions.

Now no one except Claudia McPhail has write access to that branch, and all pull requests require at least one review before they can be merged.