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 Squish 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 Squish 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 Squish 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 Squish 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 Squish Test Center.
• Timeout (in milliseconds) determines how long Git is allowed to search for a file until the request is canceled.
• Path to repository root directory stores the path to the Git repository root folder on the machine that runs Squish Test Center.

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

• The repository checkout location provided to Squish 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. Squish 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 Squish 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 Squish Test Center.

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. Squish 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.