Community Analyzers

Unlike Core analyzers, Community analyzers do not run on DeepSource’s infrastructure. Instead, they are run on CI systems and the results are reported to DeepSource. This approach allows you to use DeepSource with a broader range of technologies and languages, and manage the issues in a centralized dashboard. Furthermore, this integration enables you to leverage DeepSource’s features such as Quality Gates, Issue diffing, ignore rules setup, for the issues identified by these Community Analyzers.

​

Supported Analyzers

Issues detected by these analyzers can be found in the Analyzer Directory under the respective analyzer. For suggestions regarding additional analyzers you’d like DeepSource to support, please submit your request at roadmap.deepsource.com. We regularly review these submissions and consider them as we update our product roadmap.

​

Setting up Community Analyzers on your repository

Incorporating Community Analyzers into your workflow is a simple process.

1. Begin by adding the analyzer into your .deepsource.toml configuration file. This step is akin to activating core analyzers in DeepSource.
2. Set up the DEEPSOURCE_DSN environment variable within your Continuous Integration (CI) system.
3. Finally, integrate the analyzer into your CI system. For your convenience, we provide pre-formulated CI snippets for all major CI systems. Simply select and insert the appropriate snippet for the respective analyzer from the Analyzer Directory into your chosen CI system’s configuration.

Let’s go through these steps in detail. Community Analyzers accepts SARIF report and syncs the issues from the report on DeepSource. The SARIF report can be generated by running the analyzer on your CI pipeline.

1. Enable the analyzer by adding it to your repository’s .deepsource.toml config file. For example, if you want to enable Dart Analyze on your project, add the following to your .deepsource.toml file:

   toml

   Copy

   Ask AI

   [[analyzers]]
   name = "dart-analyze"
   type = "community"
   

   We recommend you perform this action from your dashboard by navigating to the respective Repository → Settings → Configuration and then clicking on the Regenerate Configuration button. In case, you are activating a repository for the first time, please use the Activate a repository feature from your team’s dashboard.

   The following steps can only be performed after activating a repository. In case, you are activating a repository for the first time, please commit the configuration first before continuing.

2. Set up DEEPSOURCE_DSN environment variable for the project in your CI/CD pipeline. The DSN is used to associate the analysis report to the repository. This needs to be configured before sending the analysis report to DeepSource.

   To look up the DSN:

   1. Go to the Settings page of the repository dashboard in DeepSource
   2. Go to the General tab
   3. Click on Copy button to copy your DSN mentioned under Data Source Name (DSN)

3. Set up a workflow file to run the analyzer on your CI/CD pipeline. We want to achieve the following in the workflow file:

   1. Install and run the analyzer on an event of your choice. We recommend you do this on every push to the default branch of the repository and branches that have a pull/merge request open.
   2. Send the analysis report to DeepSource once the analyzer has run and generated a SARIF report.

   For all supported analyzers, we have ready to use workflow files for selected CI mentioned in the analyzer’s page in the DeepSource Directory. You can copy the workflow file from there, and you’d be good to go.

   Here’s an example for the Dart Analyze analyzer:

   yaml

   Copy

   Ask AI

   # A copy-paste Github Actions config to run dart-analyze and report the artifact to DeepSource
   name: Scan with dart-analyze
   
   on:
     # Note that both `push` and `pull_request` triggers should be present for GitHub to consistently present dart-analyze
     # SARIF reports.
     push:
       branches: [main, master]
     pull_request:
   
   jobs:
     scan:
       runs-on: ubuntu-latest
       permissions:
         contents: read # for actions/checkout to fetch code
         security-events: write # for github/codeql-action/upload-sarif to upload SARIF results
         actions: read # only required for a private repository by github/codeql-action/upload-sarif to get the Action run status
       steps:
         - name: Code Checkout
           uses: actions/checkout@v3
           with:
             ref: ${{ github.event.pull_request.head.sha }}
   
         - name: Setup Dart
           uses: dart-lang/setup-dart@v1
   
         - name: Run Dart Analyze
           run: dart analyze > dart_analyze.txt || true
   
         - name: Dart Analyze to SARIF
           uses: advanced-security/dart-analyzer-sarif@main
           with:
             input: dart_analyze.txt
             output: dart_analyze.sarif
   
         - name: Upload SARIF report to DeepSource
           run: |
             # Install the CLI
             curl https://deepsource.io/cli | sh
   
             # Send the report to DeepSource
             ./bin/deepsource report --analyzer dart-analyze --analyzer-type community --value-file ./dart_analyze.sarif
   
           env:
             DEEPSOURCE_DSN: ${{ secrets.DEEPSOURCE_DSN }}
   

- name: Upload SARIF report files to DeepSource
       run: |
         # Install the CLI
         curl https://deepsource.io/cli | sh

         # Send the report to DeepSource
        ./bin/deepsource report --analyzer <analyzer-shortcode> --analyzer-type community --value-file <path-to-sarif-report>

​

How does it work?

Once you have set up the analyzer on your project, open a pull request or push a commit to your default branch. You should be able to see the issues from the analyzer on your project’s dashboard in DeepSource.

Please note that the Issues are shown on the dashboard only for the reports sent for runs on the default branch of the repository, as configured on DeepSource.

For a Pull/Merge Request, you’ll see only new issues in the files that are introduced and not all the issues. This is to help you focus on the new issues introduced by the PR and not deal with noise from issues that are not related to the changes in the pull request.