Salesforce released (as of Spring 2024) their official GitHub action for Code Analyzer (SFCA) on the GitHub marketplace. As of May 2025, there are now 2 versions listed there; action v1 which links to SFCA v4.x, and action v2 which links to the newer SFCA v5.x. This doc contains instructions for integrating that action into your Salesforce DevOps Pipeline, and using it 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, assess the v2 capabilities, and copy the example usage shown here, which lays the foundation to run SFCA on pushes into your repository.
Navigate to your repository in GitHub.
In the .github/workflows/ folder create a new file and paste this example output from GitHub, tweaking the filename/name of the workflow as required.
Some key notes before saving:
Using the example screenshot above, and respective line numbers:
Line 2 - states '
on: push' - this means for every commit to any branch, the code analyzer will run. You could consider modifying it to be similar to the following:
The above would allow manual triggering, scheduled triggering at midnight every day using cron, and also when PRs are raised to particular branches (although as per the note below, it scans the whole branch, not the PR delta).
This changes the 'example usage' behavior but when this is triggered is likely to be very specific to your processes.
Lines 10-23 - these cover necessary prerequisites for the various engines SFCA v5 utilises, such as Java and Python, and act as a gatekeeper in case the chosen runner (ubuntu-latest) doesn't have them installed or aren't the correct the version.
Line 35 - this contains the run arguments for Salesforce Code Analyzer, and the main things to note are:
The workspace 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.
It's outputting 2 files; a html report, and a json file. You may only want one or the other of these, or could select one of the other options from this list.
Lines 40-43 - these are the 'threshold' values you may want to tweak depending on your risk tolerance to classify the run as failed. 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, any above a '3' (Moderate) severity, or a combination.
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)
Note: for the workflow to be triggered manually, it must be present on the default branch.
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 (remembering this is for the full branch, not the PR delta!)
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, as explained here.