Salesforce has released (as of spring 2024) their official GitHub action for Code Analyzer on the GitHub marketplace. This doc contains instructions for integrating that action into your Salesforce DevOps Pipeline, and using in conjunction with Gearset as a status check.
Note: this only applies to users who are using GitHub as their version control provider. Find out more about Gearset Pipelines and how to set up your integration with GitHub.
Setting up the GitHub action
Navigate to this page in the GitHub marketplace, and copy the example usage.
Navigate to your repository.
In the .github/workflows/ folder create a new file and paste this example output from GitHub.
Some key notes before saving:
Line 2 - states '
on: push' - this means for every commit to any branch, the code analyzer will run. Consider using something like the following to only run this on PRs to specific branches:on:pull_request:branches: ["Integration", "Hotfix"]This changes the 'example usage' behaviour but when this is triggered is likely to be very specific to your processes.
Line 21 - this contains the run arguments for Salesforce Code Analyzer, and the main thing to note is the target is '.', which means all 'checked out' files. This means all the directories/sub-directories in your source branch for the PR.
This is important to note as even if your PR only contained X Apex class changes, you'd actually get the results for all Apex classes in your source branch, and you'll need to sift through the results to find them.
Line 26-28 - these are the 'threshold' values you may want to tweak depending on your risk tolerance. For example, you may actually want the check to fail if any more than 5 violations are found rather than the 10 detailed in the example, so could tweak that number.
Getting the file into your Pipeline
Once happy, commit your changes into a new branch, ready to PR into your main environment branches used in the Pipeline.
Once it's present in a new branch, you can PR that to 'main' to get it into your base branch, and available for testing (depending on your selections for the on: trigger section, as explained above)
Sync the new action with the rest of your Pipeline
Using the sync PR button in Gearset make sure that the file you've added to the main branch is present in the other environments.
More detail on that feature can be found here.
Testing the new GitHub action
After setting up the files and syncing the branches it's time to test your new action.
Open a new feature branch, commit a piece of code to the branch, and open a pull request (more detail on this process can be found here).
At the point of the pull request being opened the action will be triggered, and surfaced in Gearset as a status check on that pull request.
Click 'Details' next to the run results to find the results summary in GitHub and dive into the details.
Some key points
You can edit the file to your needs as required (to trigger on different branches/PRs only, to run different engines etc) but be aware of the divergence to the formal action.
Due to the way GitHub attaches status checks to particular commits, you may see multiple runs of the Salesforce Code Analyzer appear in your GitHub PR view and Gearset Pipelines view, due to the original commits retaining the history of previous runs.