This section explains general code review configuration options (options that apply to both pre-commit and post-commit processes).
Sections include:
Configuring Code Review Preferences
- Choose Parasoft> Preferences to open the Preferences dialog.
- If you have not already done so, configure source control preferences as follows:
- Select the Parasoft> Scope and Authorship category in the left pane of the Preferences panel.
- Enable Use source control (modification author) to compute scope.
- Select the Parasoft> Source Control category in the left pane of the Preferences panel.
- Specify your team’s source control repository (see Connecting to Your Source Control Repository) or enable the Use DTP settings option (see Connecting to Parasoft Development Testing Platform).
If you have not already done so, configure Team Server preferences (see Connecting to Parasoft Team Server).
- Storing code review data in Report Center is recommended for more efficient storage. See Connecting to Project Center for details.
- (Desktop installations only) Select the Parasoft> Code Review category in the left pane, then complete the Code Review settings as follows:
- DTP Settings
Displays the DTP server host name you have configured. You can disable the Default option to modify the port number. - General Settings
- User name: Enter a unique Code Review name for the current user. The same user name specified here should also be specified in the Code Review Test Configuration.
- Show user assistant during scanner run: This enables a user assistant, which allows you to specify a task identifier, enter notes, specify review priority, and enter a specific reviewer or monitor for each Code Review run. This is intended for pre-commit code reviews.
- Notify me about new or updated reviews every ___ minutes: Select this if you want to be alerted when you need to review code and/or when code that you authored has been reviewed. This option is recommended.
- Show completed tasks by: If you want the code review tasks tree to show completed tasks as well as active ones, enable this option and specify the range of completed tasks you want shown. For example, if you want to see all tasks completed within the past week, choose 7 days.
- Compare Editor
- Reuse single compare editor: If want Code Review to open each revision in the same editor, enable this option.
- Close compare editors on commit review action: If you want the compare editor to be closed when a revision is committed, enable this option.
- Show structural changes: If you want the compare editor to show structural changes, enable this option.
- Show suppressed parts: If you want the compare editor to show details from code excluded from analysis (as described in Hiding Differences for Specific Pieces of Code), enable this option.
- Show the newer source on the left | right: Specifies where the most recent source is positioned in the comparison editor.
- Opening Local Sources in Existing Projects
- Use source control to recognize local sources: If you want to allow Parasoft to use source control data in order to better recognize the sources found, enable this option.
- Always open without asking when path of a local source is different than remote path (single source matches only): If you want to force Parasoft to always apply a local source path (if it is different than the remote one), enable this option.
- Show warning when the file has been changed since issue was created: If you want to receive warnings if the Code Review task becomes outdated (i.e., because the current source code has been modified since the Code Review task was created), enable this option.
- Appearance: Allows you to customize what labels are used in the code review task tree and determine whether tasks for multiple revisions of a file are merged.
- DTP Settings
- (Desktop installations only) Select the Parasoft> Code Review> Team category in the left pane, then complete the Code Review settings as follows:
- General settings: Indicate whether you want to use the default workflow or the restricted workflow. For an overview of these options, see Workflow Overview. If you prefer, you can enable a restricted workflow directly on Team Server using the property key path
/usr/{user}/codereview/workflow
, and the property valuerestrict
. If you want to revert to a default workflow policy, change the property value todefault
(see "Managing Team Server Data" in the Development Testing Platform documentation). - Import tasks from Team Server to Report Center: Optimizes performance by storing network data in the database. See Importing Code Review Data from Team Server to the Report Center Database.
Task categories: This allows you to customize the list of categories that reviewers can use to categorize their comments.
- General settings: Indicate whether you want to use the default workflow or the restricted workflow. For an overview of these options, see Workflow Overview. If you prefer, you can enable a restricted workflow directly on Team Server using the property key path
7. Click Apply to apply your settings.
8. Click OK to set and save your settings.
Configuring Test Configurations for Scanning
Test Configurations control how code reviews are prepared, and the appropriate configuration varies depending on whether your team has a pre-commit or post-commit code review process.
- For details on configuring Test Configurations for pre-commit code review processes, see Configuring and Running Pre-Commit Code Review Scans.
- For details on configuring Test Configurations for post-commit code review processes, see Configuring and Running Post-Commit Code Review Scans.
Hiding Differences for Specific Pieces of Code
If you do not want the compare editor to show diffs that occur within specific blocks of code:
- Add the
codereview-begin-suppress
comment at the point in the code where you want to stop showing differences. - Add the
codereview-end-suppress
comment at the point in the code where you want to resume reporting of differences.
By default, suppressed code will not be shown in diffs for related code review tasks (for example, a diff highlighting a code change immediately following or preceding suppressed code). If you later want to view the suppressed content in diffs:
- Choose Parasoft> Preferences to open the Preferences dialog.
- Select the Parasoft> Code Review category in the left pane.
- Enable the Show suppressed parts option.
Troubleshooting Unpublished or Skipped Reviews
Unpublished Reviews
If the Test Progress tab reports that reviews were not published, this is a sign that your configuration has undefined authors.
For example, assume that your code review results are as follows:
Two files were scanned and two revisions were accepted, but there is no code review package to publish because the scanned code had modifications made by the user "pietrek." This user is not listed in the Code Review> Authors tab of the test configuration.
To correct this problem:
- Add the author to the test configuration’s Code Review> Authors tab.
- Either assign a reviewer to review all code by this author, or assign a reviewer to the area of source code where this author’s revisions occur.
- Re-run the test configuration.
Skipped Reviews
If the results show that reviews were skipped (with undefined users and/or unmatched paths by author), this is a sign that the modified code is not properly assigned to a reviewer.
For example, assume that you have the following results
and that your report indicates the following:
You can resolve the problem by modifying the Test Configuration to either assign that area of code to a reviewer, or to assign a reviewer to all code modified by that author.
Understanding How Code Review Packages are Created
Each code review package is defined based on the author changes (commits).
- In post-commit code review, changes are collected when the automated scan runs each day.
- In pre-commit code review, the code author specifies which changes should be included in the package.
Any reviewers and monitors mapped to that author are then assigned to the package. If the package contains code from the project areas that other reviewers or monitors are set to review, those reviewers/monitors are also assigned to this package.
If a package is created and no reviewers or monitors are set to review the related author or project area, then no review tasks will be generated for that package.
Separate packages are not created for different paths (regions). As a result, reviewers assigned to different paths may be working on the same package. They should decide for themselves which paths they want to review. This maintains the integrity of tasks that may spread across multiple reviewers' assigned areas. If a reviewer wants to see which files in a package were matched to him because they belong to "his" assigned region, this information is available in the Code Review view.
Importing Code Review Data from Team Server to the Report Center Database
Storing data in the Report Center database is more efficient than storing them as flat files in Team Server. Team Server storage is supported for backwards compatibility, but Report Center storage is strongly recommended.
To migrate code review data from Team Server to Report Center:
- Choose Parasoft> Preferences.
- Open Parasoft> Code Review> Team.
- Click Import, then complete the dialog that opens. This allows you to import all code review data or only packages from specified data range. If existing items are imported, they will be duplicated.
The average time needed to import one Code Review package from Team Server to the Report Center database is approximately 30 seconds. A safe estimate is to assume that you can import about 2880 packages per day.