Integrate repositories

Administrators can specify different types of repositories and link them to projects. This enables you to quickly access your test sources from the results shown in the Verifications view or easily compare your visual verification points (VVP) with the expected VVP from a repository.

Set up a repository

To add and configure repositories, select Global Settings > Repository Integration. To add a repository for Test Center to use, click the Add Repository button. In the Add Repository dialog, select the type of repository to add. You can find more information on the supported types of repositories below.

Fill in the required repository settings and click Submit. To change repository settings, click the Update button. Project mappings and subfolders are updated separately. Click Connect a Project and select the Test Center project that will use this repository. Click Connect to confirm the connection. You can link multiple projects to one repository this way.

Repository settings for Git integration

In the table that lists the connected projects, click the Edit button to specify subfolders for each project. Subfolders are used to limit the search to one repository. You can use them to avoid possible search duplicates and to increase performance. If at least one subfolder is specified for a project, only its specified subfolders are searched.

Enable or disable repositories by clicking the switch next to the repository name. To remove a repository and all its settings (including project specific mappings), click the trashcan icon.

Access test source files

If a project is connected to an active repository, click the file paths and stack traces below a verification to open the Verifications view, which displays the contents of the file with the line from which the verification originates highlighted.

Viewing the test source in the Verifications view

Git repository settings

This repository type requires a Git client and a clone of your repository on the machine that runs Test Center. Specify the following settings:

• Automatically pull new data when viewing files determines whether the Git repository will perform a pull command to always have the newest state of the remote checked out.
• Push to remote when updating VP file determines whether updating a verification point file will only create a local commit or whether the change should also be pushed to a remote repository.
• Default Branch specifies the branch to use for verification point file updates when no branch is specified via the .git.branch label.
• Repository URL stores the URL Template for the Source Control Managment (SCM). It must contain the tag $\{COMMIT\}, as Test Center will replace it with the commit SHA in order to create a link to the SCM.
• Filepath to repository client executable stores the filepath to the Git executable on the machine that runs Test Center.
• Timeout (in milliseconds) determines how long Git is allowed to search for a file until the request is canceled.
• Path to workspace directory where revision of the repository can be stored during execution stores the path to the directory that will store copies of the repository for Test Execution. It is recommended to configure a directory that is not inside the Path to repository root directory.
• Path to repository root directory stores the path to the Git repository root folder on the machine that runs Test Center.

For the Git integration to work correctly, make sure the following applies to your Git repository:

• The repository checkout location provided to Test Center shouldn't be used by other applications nor for development.
• The repository will need a default remote for the automatic pulling to work. Pull conflicts need to be resolved by an admin. Test Center itself provides no conflict resolution.

Filesystem repository settings

This repository type requires a copy of your test files on the machine that runs Test Center. Specify the following setting:

• Path to repository root directory stores the path to the root folder (used for searching) on the machine that runs Test Center.
• Path to workspace directory where revision of the repository can be stored during execution stores the path to the directory that will store copies of the repository for Test Execution. It is recommended to configure a directory that is not inside the Path to repository root directory.

Special report labels for version control

Some repositories may support version control. You can use special report labels (see Upload results) to indicate which revision of test sources the results originated from. Test Center detects this label and automatically fetches the version of the file from that revision. The following labels are supported:

• .git.revision=<commit-hash> is used for the Git integration. For example: .git.revision=7c47eb6
• .git.branch=<branch-name> is used by the Git integration to determine which branch should be used for verification point file updates (see Git repository). For example: .git.branch=main

Git Commit History Dialog

The dialog can show you the commits that happened between two test runs, to help you determine which changes have caused the tests to fail.

Dialog with commit history of a repository

If a project is connected to an active repository, from the Explore view you can view the commit history dialog, by clicking the Commit History button.

Commit History Button in Explore page

The dialog will use the labels .git.revision and .git.branch to fetch the history and redirect you to the commit of the current batch. Previous batches from the Explore views Older Batches column can also be seen in the dialog, if they are labeled with .git.revision. The dialog will show the batches and their overall passing or failing result state next to their associated commits.

When the repository setting Repository URL is set, and contains the tag ${COMMIT}, commit links are generated to the Source Control Manager.

EXAMPLE:

https://github.com/ACCOUNT/REPO/commit/${COMMIT}
https://gitlab.com/ACCOUNT/REPO/-/commit/${COMMIT}

Users can select which history is displayed from a dropdown when several repositories are associated with the project.

Users will be able to select which revision should be focused when multiple reports are labeled with different values of .git.revision label.

Import Test from Repository

You can import test suites and cases from the repository to a connected project. Within the Test Management, clicking Repository Information button will show all connected repositories and will allow you to adjust the branch you want to import tests from. Clicking the Import Tests button will start the 'import' process. This might take some seconds, depending on the amount of tests found.

Importing test, allows them to be added to Test Plans and even schedule their execution, without having to upload test results.

Test Path Matching

In Test Management, it is possible to verify that a test can be found and uniquely identified within the connected repositories, and where it is located on the filesystem Selecting any test, will show its details, including the test directory found by Test Center.

Test Management Details View with a found Test Path

If multiple locations have been found, then all paths will be shown, along with a warning. When multiple locations are found, Test Center will no be able to execute automated tests. Adding a subfolder mapping for your project might solve this problem.