You can customize the analysis configuration by editing the
.deepsource.toml file located in the repository's root directory.
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.
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.
Set the base branch for analysis by DeepSource. Your issues tab will be populated with the issues found on this branch.
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.
If you're using private submodules, it's important to grant DeepSource access to them through an SSH key to enable proper analysis.
If you see an error message about cloning, you would need to give read access to the submodules. Here's how:
- Navigate to
Settings > General, look for the
SSH accesssection and click on
+ Generate SSH key pair.
- Copy the key and paste it as a deploy key in the 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.
To enable DeepSource to retrieve external private dependencies in your repository, you'll need to grant SSH access by providing a public key. You can choose to copy, regenerate, or remove the key as needed.
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.
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.
On this page, you can manage how you track the code coverage of a repository.
Refer to the Test Coverage analyzer for steps on how to setup code coverage on a repository.
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.
This setting is visible only for a GitLab repository.
Our GitLab integration comes in two modes,
- Commit Status: We use the GitLab Commit Status API to create a pipeline. This can be used to block merges based on the results from DeepSource. This is the default mode for any new repositories onboarded on DeepSource after this change was released (May 19, 2022).
- Comments: We post a comment on the respective merge request with the analysis results. This is deprecated and will be removed soon.
You can choose between these two integration modes on a per-repository basis. Learn more.
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.
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.
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.
You can add embeddable badges with data on the number of active or resolved issues in this repository to your project's README, wiki, or website. These badges can be formatted in Markdown, AsciiDoc, HTML, or reStructuredText.
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.
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.
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.
Updated 2 months ago