DTP enables you to compare changes in the codebase as it evolves. If your organization builds software continuously, then using builds for comparison provides insight that wouldn't be possible using a traditional date-based approach to comparing data. The Build Administration page provides visibility into build activity and information stored in DTP.

In this section:

Accessing the Build Administration Page

Click on the Build Administration - Statistics widget to open the build administration page.

 

If you know the filter ID, you can manually enter the report URL:

http://<HOST>:<PORT>/grs/dtp/reports/builds?filterId=<ID>

Adding a Descriptive Tag to a Build

You can add a descriptive tag to a build, making it easier to identify from the build administration page. Tags added this way will appear below the build ID on the build administration page as well as in the build audit report. To add a descriptive tag, click the pencil icon next to the build ID and enter the desired descriptive text in the dialog that appears. Descriptions cannot exceed 128 characters.

Locking and Archiving Builds

You can lock a build to prevent DTP from accepting new reports tagged with the same build ID. Locked builds commonly mark the end of a development phase. You can archive a build to save the XML report files associated with a build ID, including the test and coverage details. DTP only keeps test and coverage details for the last two builds by default, but you may want to archive all data associated with a specific build so that existing test and coverage details are not deleted.

Archive a build to download reports

A build must be archived in order to download the XML, HTML, or PDF version of the report. See Build Audit Report for additional information.

  1.  Add the Build Admin widget to your dashboard and click on a segment you want to investigate to open the Build Administration page. Make sure that the widget settings are configured to the appropriate filter. See Build Administration - Statistics and Adding Widgets for additional information.
  2. Click the appropriate icon to lock, archive, or delete a build (also see Deleting a Build).
     
    All XML report files associated with archived builds are preserved in the <DTP_DATA_DIR>/data/_DEFAULT_/dc/baselined/<BUILD_PRIMARY_ID>/<RUN_ID> directory, where <BUILD_PRIMARY_ID> is the ID (primary key) of the build in the database and <RUN_ID> is the ID (primary key) of the run in the database.
    You can unlock or release a build by clicking the updated icon.

    When the build is released, the XML report files will remain in the subdirectory until DTP Data Collector prunes the system. Data Collector checks for data that can be pruned several times a day.

Deleting a Build

If the data associated with some runs becomes unreliable, you can search for builds associated with the compromised runs and use the REST API to delete the data from the database. For example, if the source control system goes offline, then authorship, branch information, and other data may lose integrity and have a negative impact on the effectiveness of reporting mechanisms in DTP. If the system under test (SUT) experiences a critical failure, the test results associated with runs that were executed during the failure may represent "noise" and not actual regressions.

Data removed from the database is at the build level, so all data associated with the build will be deleted, even if the removal occurs across different runs. By default, Parasoft code analysis and test execution tools generate unique builds daily, so deleting data associated with a build will likely result in deleting all data for that day.

Delete the Data Using the Build Administration Page

  1. Add the Build Admin widget to your dashboard and click on a segment you want to investigate to open the Build Administration page. Make sure that the widget settings are configured to the appropriate filter. See Build Administration - Statistics and Adding Widgets for additional information.
  2. Find the build associated with the date that should be deleted and click the trash icon. 

Deleting a Build Using the REST API

You can delete a build using the REST API. The API call for deleting a build is:

DELETE https://<HOST>:<PORT>/grs/api/v1.12/builds/<NAME_OF_BUILD>

If the build name contains special characters, including spaces, you must escape those characters to work in a URL path.

Additional Details About Deleting Builds

  • You can only delete one build at a time.
  • If Data Collector is processing reports while you are deleting a build, DTP performance related to deleting the build will be impacted. This is due to simultaneous database access.
  • For optimal performance with large sets of data, turning Data Collector off prior to deleting builds is recommended, but remember to start Data Collector when finished.
  • Static analysis findings stored in the DTP database may be associated with many builds. As a result, when a build is deleted, static analysis findings are not deleted from the database. If you want to also delete static analysis findings not associated with any builds, you can use the DTP Database Pruning CLI from the Parasoft Marketplace.

Build Audit Report

Click on a build in the Build Administration page to open the Compliance Report for that ID. The Compliance Report shows all artifacts associated with a baselined build, such as environment attributes, test configuration used, and test results, so that you can understand how well the build is tested. See Build Audit Report for details.


  • No labels