Manage the source code management servers
Squash TM allows you to send test cases in Gherkin or BDD formats written in Squash TM to a remote GitHub or GitLab repository. The configuration of these source code management is managed from the "Servers > Managing source code management servers" page of the administration.
To access the configuration of a source code management server, you must have installed the Git freeware plugin.
Add, Modify, and Delete a source code management server
From the source code management server management table, it is possible to add or remove one or several servers.
When creating a server, the Name, Type and URL fields must be filled in. The name of the server is free. The server's URL must correspond to the base URL of the Git account. It must contain the group or the username at the end. For example, if the 'Squash' user's has repositories in 'github.com', the URL to fill in is 'https://github.com/Squash'.
To create several servers in a row, click on the [Add another] button.
By clicking on the line number # or the name of a server, its consultation page is displayed allowing to complete configuration.
From the consultation page of a source code management server, several actions are possible:
- Change the name or URL of the server
- Define an authentication protocol
- Fill in the connection identifiers
- Enter the committer's address
- Add or remove repositories
- Delete the source code management server record using the [...] button.
Configure source code management server
To use a server to transmit scripted test cases or link automated scripts to test cases you must declare repositories on the server. Repositories must be cloned when transmitting scripts from Squash TM. In this case, it is necessary to set an authentication to allow Squash to connect and write in the remote repositories.
Setting up server authentication
Authentication to the source code management server is handled by the 'Authentication Protocol' and 'Authentication Policy' blocks.
In the case of a GitHub server, you must choose 'basic authentication' protocol and fill in the 'Login' field with the user's login and in the 'Password' field put a Personal Access Token previously generated from the 'Settings > Developer settings > Personal access tokens' section of GitHub.
In the case of a GitLab server, several token types exist:
- for a personal access token or an impersonation token, choose 'basic authentication' protocol and fill in the 'Login' field with the user's login and in the 'Password' field put the token ;
- for the other token types, select the 'token authentication' protocol and fill in the 'Token' field with the token.
The token must have read and write permissions to be able to clone the repositories and transmit scripted test cases.
Enter the committer's email address
The 'Commit Policy' blocks allows you to enter the email address of the Squash user who is committing into the remote repository. If this field is not filled in, this value is replaced by an empty string during the commit.
Add, modify and delete a repository
To transmit Gherkin or BDD test cases written in Squash to a remote repository, it is necessary to clone the repository on the server hosting Squash. To do this, you must register the repository in 'Repositories' block by checking 'Duplicate the repository' box:
- Name of the remote repository (required): the name of a repository must match to its name on the remote server as it is used to build the full URL of the repository (for example : https://www.github.com/UserName/RepositoryName)
- Working branch (required): the working branch is the branch on which files will be pushed to the remote repository. This branch must exist in the repository.
- Path of the local repository (required): this path is the place where the repository will be cloned on the local server hosting Squash TM. If the directories in the path do not exist, they will be created by Squash TM. The target directory may already exist but in this case it must be empty. The local repository is a directory that should not be deleted or modified by another person to ensure proper operation in Squash TM. It is best to reserve a folder on the local machine for Squash repositories, and make sure this folder is stable (not a temporary folder).
- Path of the working directory (optional): the working folder is the path to the folder relative to the "repository path" in which .feature or .robot scripts will be written. If this field is filled in, the folder must already exist in the repository. (Warning: this path must not start with /).
For a GitLab server, if a "project token" or a "group token" is used, the .git extension must be added at the end of the name of the remote repository (example: repo01.git)
To finalize the configuration of a repository created to transmit test cases, you must go to the project's configuration page: Associate a source code management server to a project.
To manually associate an automated script stored in a remote repository to a test case present in Squash TM with the 3 Squash Orchestrator fields, it is not necessary to clone the repository that contains the script. You just need to fill in the repository name, the branch name and uncheck 'Duplicate the repository' box when adding the repository.
Once a repository has been registered, only the working branch can be modified. After verifying the existence of the branch on the remote repository, the commit history of the new branch is retrieved from the remote repository and the local repository is updated to the latest revision.
Deleting a repository in Squash TM does not delete it in the source code management server. The clone of the repository present locally on the server is not deleted either. Therefore, after deleting a repository in Squash TM administration, the local repository on the server must also be deleted manually to permanently remove the clone.
To learn more about transmitting scripted test cases (Gherkin or BDD) written in Squash TM to a source code management server, go to the page transmit a scripted test case to a source code management server.