DTP can display sources directly from your source control management system (SCM) in Explorer Views. This method uses less server space compared to Displaying Source Code from Test and Analysis Tools because copies of the sources are not collected and stored on DTP.
To enable this functionality, DTP must be configured to read sources from the SCM. In addition, the Parasoft code analysis and test execution tool (C/C++test, dotTEST, Jtest, SOAtest) must be connected to the SCM and configured to publish reports to DTP during analysis.
In this section:
Configuring Source Control Settings
The most common scenario is to configure SCM settings in DTP and enable Parasoft tools to also use the SCM connection settings.
- Enable autoconfiguration in your Parasoft tool by setting the
dtp.autoconfig
property totrue
in the tool's .properties configuration file (also see Autoconfiguring Code Analysis and Test Execution Tools). - Choose Report Center Settings from the settings drop-down menu and click Projects. You can also configure SCM settings globally. See Configuring Parasoft Tool Settings for All Projects.
- Locate and click on your project to access the settings.
- Specify SCM settings in the Parasoft Tool Field. Specific SCM settings are documented in the Parasoft tools user guides. See your tool's documentation for details.
DTP supports many SCMs out of the box and can be extended to support systems that are not natively supported (contact your Parasoft representative). Each SCM has a different set of properties that must be configured.
Customizing Autoconfigured SCM Settings for DTP
In some cases, settings reused by Parasoft tools and DTP require additional customization. For instance, DTP may require different SCM credentials than the tools. Autoconfiguration can still be used by adding the DTP prioritizes the The following precedence of overwriting settings is used in DTP when the same setting appears in Global Tool Settings and project-specific Parasoft Tool settings:server.
prefix to identify the setting as a DTP Server-only setting. In the following Parasoft Tool Settings, the SVN executable directory is specified for the Parasoft tool with the scontrol.svn.exec
setting, but for DTP the directory is set with server.scontrol.svn.exec
:scontrol.svn.exec=C\:\\Program Files\\svn\\bin\\svn.exe
server.scontrol.svn.exec=/usr/bin/svn
scontrol.rep1.type=svn
scontrol.rep1.svn.url=http\://foo.bar.com/svn/repos
scontrol.rep1.svn.login=foo
scontrol.rep1.svn.password=65707c
server.scontrol.rep1.svn.login=bar
server.scontrol.rep1.svn.password=19787a
server.
prefix value if the same non-prefixed also appears.server.
prefixserver.
prefixserver.
prefixserver.
prefix
Displaying Sources from Git Repositories
You will need to configure DTP as outlined below in order to display your tested project's source code from a Git repository.
Create a local clone of the Git repository on the machine where DTP is installed. If it's not already installed, download and install the Git client, then choose a location for the clone and run:
git clone --mirror <URL_TO_REMOTE_REPO>
Do this for each Git repository that you test with Parasoft tools and want to see the tested source code in DTP.
In order for DTP to show the proper code, you need to ensure that your clones stay up to date. To update a clone, run:
git remote update <URL_TO_REMOTE_REPO>
It is recommended that you automate this task, for example with a Jenkins job or a Linux cron job. Do this for each repository you cloned in the step above.
Within DTP, go to the Report Center Settings and configure the tool settings for your DTP project so that it points to your local Git clones. See Configuring Parasoft Tool Settings for Projects for more information about this process. The example below shows a configuration for two Git repositories,
scontrol.rep1.git.workspace
andscontrol.rep2.git.workspace
, but you should configure for as many repositories as you cloned.scontrol.rep1.git.workspace=<LOCAL_CLONE_DIRECTORY> scontrol.rep1.git.branch=master scontrol.rep1.type=git scontrol.rep1.git.url=<URL_TO_REMOTE_REPO> scontrol.rep2.git.workspace=<LOCAL_CLONE_DIRECTORY> scontrol.rep2.git.branch=master scontrol.rep2.type=git scontrol.rep2.git.url=<URL_TO_REMOTE_REPO>
Displaying Sources from SVN Repositories
The following configuration is an example of an SVN connection.
scontrol.rep.type=svn scontrol.rep.svn.url=https://svn_server/ scontrol.rep.svn.login=username scontrol.rep.svn.password=password scontrol.svn.exec=/usr/bin/svn
DTP can track canonical files that appear in different SVN branches if the scontrol.rep.svn.url
setting is configured properly. This settings specifies the SVN repository URL.
Configure the scontrol.rep.svn.url
setting to the node containing the project, but do not include the project name.
For example, if a file in SVN is part of a project named “mina” with the following absolute path:
https://svn.apache.org/repos/asf/mina/trunk/examples/src/http/BogusSslContextFactory.java
The CLI settings should be set to:
scontrol.rep.svn.url=https\://svn.apache.org/repos/asf
Do not include a trailing slash (/). Make sure to keep this consistent across all projects.
Troubleshooting Issues with Source Control System
When source code cannot be displayed from Source Control System:
- Ensure that the report.xml file is published to DTP has source control information. Check that
<Repositories..>
section is present. If this is not the case, then the Parasoft tool configuration is incorrect - Check the source code panel in an explorer view for important information.
- Ensure that all repository settings are present in Parasoft Tool setting. Credentials and other repository settings are necessary to display source code
- Ensure that the source control client is available to DTP and correctly configured. Ensure that the client can access the source code using credentials that are configured for DTP.
- For some source control systems, such as Git, ensure that the repository is cloned and up-to-date at DTP. An external cron job may be necessary for Git to update the local repository regularly.
- Verify that your SCM supports modifying, moving, or copying sources during build in order to rule-out disconnecting from the original source control system.