Analyzing source code
This document shows how DeepScan analyzes your files in the project.
- DeepScan fetches the code of default branch from the GitHub or GitLab project.
- DeepScan analyzes the code. It can take a few minutes when the project is large or the service is busy for other requests.
Automatic analysis means the analysis automatically occurred by the following changes:
- When new commit is pushed to the branches you have been analyzed
- When new review request is created
- When new change is pushed to a review request
DeepScan can get notified this changes by webhooks from GitHub or GitLab. DeepScan will automatically and continuously analyze these changes so you can manage the up-to-date status of your project and check new code as an automated code review.
Automatic analysis by webhooks just works because DeepScan tries to configure your project with webhooks when you add a project.
If you want to disable our automatic analysis, go to the settings of your project on GitHub or GitLab, delete our webhook under Webhooks. (Note that its url starts with
But keep in mind that at least one of your team members should have an owner permission for the project because the request's status checks require the permission. In case all of your team members do not have an owner permission, you can see an warning like:
Once one of your team members get to have an owner permission for the project, an automatic analysis will resume the request's check hereafter.
Analysis for review request
By the webhooks added in creating a project, DeepScan automatically analyzes the review request commit whenever a new request is created and/or updated for your GitHub (pull request) or GitLab project (merge request).
After calculating new and resolved issues between the request commit and the base one, DeepScan sends the status check to the repository according to the Commit Status setting in the project settings:
|New issues||Resolved issues||Status check||Commit status setting|
|No new issues||-||Success|
|New issues||Unresolved issues||Success||Set commit status success always|
|Failure only when the issues with High impact are found||High issues are found|
|Failure only when the issues with High or Medium impacts are found||Medium or higher issues are found|
|Failure||Low or higher issues are found (default)|
|All issues resolved||Success|
You can see the above status check in your GitHub page and by clicking Details link, you can see the detailed issues in the DeepScan dashboard.
Also, you can manage the issue status for the review request. For example, you can set the status as 'False Positive' so the overall status will be changed as 'Success'.
Excluding from an analysis
Excluded files by default
Conditions for these files are as follows:
- All files under
- Minified file:
*_min.jsor when average line length is greater than 200.
- Automatically generated
*.jsfiles from TypeScript files.
- Files over 30,000 lines.
- Files over 1.5 MB in size.
- Lines with length greater than 400.
Excluding unwanted files from an analysis
In the first analysis, it's likely that third-party libraries, test and distribution files are included and the result is somehow distorted.
For excluding files and folders, see here.
Excluding unwanted rules from an analysis
You can choose which rules to apply by selecting and de-selecting them. You need to reanalyze the project for the changed rules to take effect.
For excluding rules, see here.
Excluded rules from the test case code
In test cases, repetitive code may be present to test various aspects of the test target. As a result, some rules at Code Quality category have significantly more violations at test code. However, they are usually harmless because test cases have clear measures of success and failure.
So, the following alarms on test case code are excluded automatically to reduce noise and fixing the detected alarms as smooth as possible:
Currently, BDD, TDD and QUnit style test cases are automatically recognized.
Understanding the analysis result
After analyzing by the rules, we calculate project’s overall grade by aggregating the issues detected. A grade represents status on your project measured by issue density—i.e., the number of issues per thousand lines of code.
You can use this grade as a badge like to see the latest status directly in GitHub or GitLab.
To add a badge to your repository, copy markdown or html snippet in the project's Overview into where you want to add, like README file in the project. With this badge, you can check the latest status and navigate to the dashboard when you click.
For more information how grades are calculated, see here.