Settings
General
Analysis configuration
You can customize the analysis configuration by editing the .deepsource.toml file located in the repository’s root directory.
Clicking on Edit configuration will take you to the configuration generator, which will help you create the file easily. Once you have made your changes, simply generate a pull request with the updated configuration file.
Analysis status
If you want to temporarily stop the analysis on your repository, you can click on the toggle. This will pause the analysis, and you can reactivate it whenever you want to resume the analysis.
Re-run analysis on all files
To re-run analysis on all files of the default branch of the repository, you can deactivate analysis and activate again with the toggle.
Analysis settings
Set default analysis branch
Set the base branch for analysis by DeepSource. Your issues tab will be populated with the issues found on this branch.
Use Git submodules
Enable this if your repository relies on code within submodules. If these submodules are private, ensure that DeepSource can access them using the SSH key as documented below.
Analysis result diffing
Baseline: Issues will be reported only for the lines that have been added or modified in the files that have been updated or added. This provides a more targeted and focused view of the code health issues. Broad: All issues will be reported in the files that have been updated or added, which may result in a larger number of notifications. Please note that this may result in more noise and make it harder to identify critical issues.
SSH access
DeepSource analyzers installs dependencies during analysis to retrieve additional context. If the dependencies are public, the analyzers can fetch them without any additional configuration. If you’re using private submodules or private dependencies, it’s important to grant DeepSource access to them through an SSH key.
To enable DeepSource to retrieve external private dependencies or submodules in your repository, you’ll need to grant SSH access by generating and adding the public key to the dependency/submodule repository. You can choose to copy, regenerate, or remove the key as needed.
- Navigate to
Settings > General, look for theSSH accesssection and click on+ Generate SSH key pair.
- Copy the key and paste it as a deploy key in the dependency/submodule repository.
If you have multiple submodules, you must add the generated SSH key to all submodules. In case of GitHub, this won’t work — it would complain that this key is in use elsewhere. To fix this, create a machine user, add the generated SSH key for that user, and give this machine user access to all your submodule repositories.
Data Source Name (DSN)
Here, you can view, copy, or regenerate the Data Source Name (DSN) for this repository. Regenerating the DSN will invalidate the old one, so be sure to replace it with the new one wherever it is being used.
Configuration
The analysis configuration for a repository on DeepSource is defined in a .deepsource.toml file located in the root of the repository. This file is essential for the analysis to be run. To edit the .deepsource.toml file, simply click on the ‘Regenerate configuration’ button, which will redirect you to the configuration generator.
Code Coverage
On this page, you can manage how you track the code coverage of a repository.
Enable code coverage tracking
Refer to the Test Coverage analyzer for steps on how to setup code coverage on a repository.
Enable report inference on the default branch
A common way developers setup CI on their repositories is to run the full test suite on pull requests and avoid running the same tests on the merge commits for when pull requests get merged to the default branch. In such a case, DeepSource’s Test Coverage analyzer may fail on commits to the default branch as no coverage report would be received for analysis.
To allow such use-cases, DeepSource provides an option to re-use coverage reports from pull requests after a merge. By enabling this option, on merge commits to the default branch, the Test Coverage analyzer will re-use the coverage reports from the last analysis on the related pull request.
Quality gates
Reporting Options
Commit Status
DeepSource publishes a commit status (also called a check or build status) for every commit analyzed with an appropriate status indicating whether the analysis passed or not. This can be used to block PR merges. This is the default behavior and cannot be disabled.
Pull Requests comment
DeepSource adds a comment on pull requests with a summary of the analysis results and metrics. This will make understanding and auditing code health problems in the code review flow easier without navigating away from the pull request. This is the default behavior for new repositories (later than February 2024) and can be disabled.
Issue Reporting
Customize the reporting of issues by selecting the categories to include and setting the criteria for failure. Additionally, prioritize reported issues based on their level of importance.
Metrics Reporting
Customize metrics reporting by selecting the metrics to be included and setting thresholds for failure. Analysis runs will be marked as failed if these thresholds are not met.
Issue priority
You can assign a priority of High, Medium, or Low to every issue introduced in this repository. Prioritizing issues can help you filter out those that are less meaningful or actionable for you.
Badges
You can add embeddable badges with data on the number of active issues, resolved issues and code coverage in this repository to your project’s README, wiki, or website. These badges can be formatted in Markdown, AsciiDoc, HTML, or reStructuredText.
Ignored rules
In this section, you’ll find all the ignore rules that you have added. To remove an Ignore rule, click on the bin icon next to it. Read more about ignoring issues.
Audit log
The audit log provides a comprehensive record of all events and actions related to the analysis and configuration of your repository on DeepSource. This includes events such as activating or deactivating analysis, creating or deleting ignore rules, adding or removing team members, as well as any other changes made to the configuration or settings of DeepSource within the repository. By reviewing the audit log, you can easily track and monitor the history of all activities and changes made within your repository on DeepSource.
Collaborators
In this section, you can view a list of all members who have access to the repository. To modify a member’s access level, simply click on the dropdown menu and select either Admin, Write, or Read-only. If you need to add a new collaborator to the repository, click on the Add Collaborator button.
New collaborators must first be invited to join the team before they can be added as repository members.
Settings
General
Analysis configuration
You can customize the analysis configuration by editing the .deepsource.toml file located in the repository’s root directory.
Clicking on Edit configuration will take you to the configuration generator, which will help you create the file easily. Once you have made your changes, simply generate a pull request with the updated configuration file.
Analysis status
If you want to temporarily stop the analysis on your repository, you can click on the toggle. This will pause the analysis, and you can reactivate it whenever you want to resume the analysis.
Re-run analysis on all files
To re-run analysis on all files of the default branch of the repository, you can deactivate analysis and activate again with the toggle.
Analysis settings
Set default analysis branch
Set the base branch for analysis by DeepSource. Your issues tab will be populated with the issues found on this branch.
Use Git submodules
Enable this if your repository relies on code within submodules. If these submodules are private, ensure that DeepSource can access them using the SSH key as documented below.
Analysis result diffing
Baseline: Issues will be reported only for the lines that have been added or modified in the files that have been updated or added. This provides a more targeted and focused view of the code health issues. Broad: All issues will be reported in the files that have been updated or added, which may result in a larger number of notifications. Please note that this may result in more noise and make it harder to identify critical issues.
SSH access
DeepSource analyzers installs dependencies during analysis to retrieve additional context. If the dependencies are public, the analyzers can fetch them without any additional configuration. If you’re using private submodules or private dependencies, it’s important to grant DeepSource access to them through an SSH key.
To enable DeepSource to retrieve external private dependencies or submodules in your repository, you’ll need to grant SSH access by generating and adding the public key to the dependency/submodule repository. You can choose to copy, regenerate, or remove the key as needed.
- Navigate to
Settings > General, look for theSSH accesssection and click on+ Generate SSH key pair.
- Copy the key and paste it as a deploy key in the dependency/submodule repository.
If you have multiple submodules, you must add the generated SSH key to all submodules. In case of GitHub, this won’t work — it would complain that this key is in use elsewhere. To fix this, create a machine user, add the generated SSH key for that user, and give this machine user access to all your submodule repositories.
Data Source Name (DSN)
Here, you can view, copy, or regenerate the Data Source Name (DSN) for this repository. Regenerating the DSN will invalidate the old one, so be sure to replace it with the new one wherever it is being used.
Configuration
The analysis configuration for a repository on DeepSource is defined in a .deepsource.toml file located in the root of the repository. This file is essential for the analysis to be run. To edit the .deepsource.toml file, simply click on the ‘Regenerate configuration’ button, which will redirect you to the configuration generator.
Code Coverage
On this page, you can manage how you track the code coverage of a repository.
Enable code coverage tracking
Refer to the Test Coverage analyzer for steps on how to setup code coverage on a repository.
Enable report inference on the default branch
A common way developers setup CI on their repositories is to run the full test suite on pull requests and avoid running the same tests on the merge commits for when pull requests get merged to the default branch. In such a case, DeepSource’s Test Coverage analyzer may fail on commits to the default branch as no coverage report would be received for analysis.
To allow such use-cases, DeepSource provides an option to re-use coverage reports from pull requests after a merge. By enabling this option, on merge commits to the default branch, the Test Coverage analyzer will re-use the coverage reports from the last analysis on the related pull request.
Quality gates
Reporting Options
Commit Status
DeepSource publishes a commit status (also called a check or build status) for every commit analyzed with an appropriate status indicating whether the analysis passed or not. This can be used to block PR merges. This is the default behavior and cannot be disabled.
Pull Requests comment
DeepSource adds a comment on pull requests with a summary of the analysis results and metrics. This will make understanding and auditing code health problems in the code review flow easier without navigating away from the pull request. This is the default behavior for new repositories (later than February 2024) and can be disabled.
Issue Reporting
Customize the reporting of issues by selecting the categories to include and setting the criteria for failure. Additionally, prioritize reported issues based on their level of importance.
Metrics Reporting
Customize metrics reporting by selecting the metrics to be included and setting thresholds for failure. Analysis runs will be marked as failed if these thresholds are not met.
Issue priority
You can assign a priority of High, Medium, or Low to every issue introduced in this repository. Prioritizing issues can help you filter out those that are less meaningful or actionable for you.
Badges
You can add embeddable badges with data on the number of active issues, resolved issues and code coverage in this repository to your project’s README, wiki, or website. These badges can be formatted in Markdown, AsciiDoc, HTML, or reStructuredText.
Ignored rules
In this section, you’ll find all the ignore rules that you have added. To remove an Ignore rule, click on the bin icon next to it. Read more about ignoring issues.
Audit log
The audit log provides a comprehensive record of all events and actions related to the analysis and configuration of your repository on DeepSource. This includes events such as activating or deactivating analysis, creating or deleting ignore rules, adding or removing team members, as well as any other changes made to the configuration or settings of DeepSource within the repository. By reviewing the audit log, you can easily track and monitor the history of all activities and changes made within your repository on DeepSource.
Collaborators
In this section, you can view a list of all members who have access to the repository. To modify a member’s access level, simply click on the dropdown menu and select either Admin, Write, or Read-only. If you need to add a new collaborator to the repository, click on the Add Collaborator button.
New collaborators must first be invited to join the team before they can be added as repository members.