Overview

You can schedule to run the project reports daily, weekly or monthly using this option. On scheduling the report, the selected report gets generated automatically on the specified date and time and the generated report is sent to the respective user through e-mail. Thus by scheduling the reports you get the data in regular intervals without manually generating it.

What's New

Previously, the project reports were available for download for the main branches. With CodeScan 22.7 update, we now support generating reports manually or by scheduling them for every project branch.

To configure scheduled reports,

1. Select the CodeScan organization and choose your project.

2. Navigate to the More tab and choose Project Reports from the dropdown.

1. Choose Scheduling option as Cron, if not automatically selected.

2. The Cron expression is a string consisting five subexpressions (fields) that describe individual details of the schedule.

1. Choose Receive Scheduled Reports as Enabled.

2. Click Run now.

An analysis scope helps you narrow your results to only the relevant issues. This reduces the noise and issues from rules that may not be relevant to certain files.

The key features of an Analysis Scope are:

• Helps you exclude certain files from detecting specific issues.

• Helps you completely ignore some files.

• Helps you exclude files from duplication detection and coverage calculations.

Follow the steps below to use the Analysis Scope feature on CodeScan cloud.

1. Open the Project under the Organization for which you need to run the analysis and navigate to Project Settings > General Settings > Analysis Scope.

1. You will now be able to view the tab, under which you can select your required specification to enable this feature during the analysis.

   • Wildcards: If you scroll the tab farther to the end, you can see a portion that says “wildcards,” under which there are rules and examples, which help you understand how to enter the specifications or part of the file name to enable this feature.

   

   
2. If we go under files, you will be able to view two options as follows:

   

   • Source File Exclusions: to exclude source code files. Specifying an exclusion means that everything under your directory will be included in analysis except the files with paths that match your exclusion pattern.

   • Source File Inclusions: Helps include only the specific source code files in the analysis. In a few corner cases, it is necessary to be explicit about what's included in analysis and leave out everything else, but that is not the normal case, and setting inclusions should not be the first thing you try when configuring a new project.

3. Once the analysis is completed, go to the Code tab to view the files as per your specified settings.

Here are a couple of implementation examples:

• For Source File Exclusions:

• For Source File Inclusions:

You can accomplish this by utilizing the "Ignore Issues on Multiple Criteria" feature in Project Settings under General Settings > Analysis Scope.

To do this, simply provide the rule key and file path name.

Example:

CodeScan offers multiple ways to manage false positives and avoid unwanted violations.

Marking False Positives

When reviewing your violations inline, SonarQube™ allows you to mark False Positives to prevent further alerts about certain issues in your code. This will block that violation from reappearing until it is unblocked.

Important Note: False positives are not carried across projects. For example, if you mark an issue as a false positive in Project One and create Project Two from the same source code, the issue will still be present in Project Two until it is marked otherwise.

Using suppressUnitTestViolations parameter

Each rule includes the suppressUnitTestViolations parameter, which determines whether any violations of this rule are reported in test methods.

There are three options for suppressUnitTestViolations in the rule configuration when adding a rule to your custom Quality Profile: Display, Suppress and Default.

• Display will always throw a violation in test classes (default)

• Suppress will never throw a violation in test classes.

• Default will be either Suppress or Display based on whether the rule applies to test classes, with the default set to Display unless specified otherwise. For example, setting suppressUnitTestViolations to Suppress for the rule AvoidSoqlInLoops would ignore the violation below:

@IsTest
class newClass {
   void method1(){
     for (int i = 0; i < 10; i++){
       insert new Account(name = ‘Name ’ + i);
     }
   }
}

Using @SuppressWarnings

The @suppresswarnings annotation provides a way to block rule violations for specific classes, methods, and fields. Although SonarQube™ allows you to mark False Positives to prevent further alerts about certain issues in your code, these changes are not remembered if you have multiple environments that aren’t linked together. Using the @SuppressWarnings annotation ensures consistency across multiple environments.

The following will ignore all rule violations for the class Test1:

@SuppressWarnings(‘all’)
class newClass {
   void method1(){
     for (int i = 0; i < 10; i++){
       insert new Account(name = ‘Name ’ + i);
     }
   }
}

Whereas this would ignore only the rules given to @SuppressWarnings as parameters within method1:

class newClass {
  @SuppressWarnings(‘cs.AvoidSoqlInLoops’)
   void method1(){
     for (int i = 0; i < 10; i++){
       insert new Account(name = ‘Name ’ + i);
     }
   }
}

The same method can also be used for fields:

class newClass {
  @SuppressWarnings(‘sf:UnusedPrivateField’)
  integer x;
}

The names of the rules can be found in:

• SonarQube™/CodeScan Cloud, by clicking on a specific rule in the Rules menu.

• IntelliJ, next to the rule violations themselves when a violation is selected. CodeScan Rules found in IntelliJ

The syntax is as follows:

• Use @SuppressWarnings(‘cs.RULENAME’) for a specific rule name

• @SuppressWarnings(‘sf:RULENAME’) is also allowed

• Use @SuppressWarnings(‘cs.RULENAME, cs.OTHERULE’) to specify multiple rules, separating each new rule with a comma

• Use @SuppressWarnings(‘all’) to ignore all rules

Using //NOSONAR

The //NOSONAR comment suppresses all rules for a single line of code:

Example:

class newClass {
   void method1() {
     for (int i = 0; i < 10; i++) {
       insert new Account(name = 'Name ' + i); //NOSONAR
     }
   }
}

CodeScan can take JSON coverage files generated by the Salesforce CLI and apply the coverage in your analysis.

If you are using the Salesforce CLI to run the analysis, see our guide here.

If you have a Git project created in CodeScan Cloud:

• Open your project and navigate to Project Settings > General Settings at the top right of the screen

• Click the CodeScan tab on the right

• Scroll down to the Testing section

• Add the JSON code coverage file name and re-run the analysis

After the analysis completes you will be able to view the coverage percentage on your project overview.

Retention Period

By default, CodeScan is set to delete inactive branches and pull requests (PRs) after 30 days, which is standard practice in SDLC for old feature branches. However, you can choose to keep inactive branches that you want to maintain.

Changing Settings for Deleting Inactive Branches and Pull Requests

To change the settings for deleting inactive branches and PRs, navigate to the project you want to adjust. Go to Project Settings > General Settings and search for "Delete inactive branches and PRs after." You’ll find the option there, and you can change the settings accordingly. The default is 30 days for all projects.

Changes to the setting will also be reflected in the Branches and Pull Requests tab.

Note: Changes only take effect after the next analysis.