Manage source code management servers
Squash allows you to send test cases in Gherkin or BDD formats written in Squash to a remote GitHub or GitLab repository. The configuration of these source code management servers is managed from the Administration > Servers > Managing source code management servers page.
Warning
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 has some repositories in github.com
, the URL should be https://github.com/Squash
.
To create several servers in a row, click on the [Add another] button.
By clicking on the ID # or the Name of a server, its consultation page is displayed allowing to complete the 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;
- Set the authentication credentials;
- Set the committer's email address;
- Add or remove repositories;
- Delete the source code management server record using the [...] button.
Configure source code management server
In order to link automated scripts to test cases, you must declare the repository containing these tests.
To transmit Gherkin or BDD test cases written in Squash to a remote repository, you also need to clone the repository on the server hosting Squash and to set an authentication allowing Squash to write in the remote repository. (Local repositories are in the folder defined by squash.path.local-git-repositories-folder
.)
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 provided token must have at least read permissions on the repository. In the case of transmitting Gherkin or BDD test cases, it must additionally have write permissions.
You have the option to choose whether or not to transmit authentication information to the execution environment.
- If the [Do not share] box is checked, the authentication information will not be transmitted to the execution environment.
This means that, when running tests, the credentials should have already been configured in that environment, e.g. by using a SSH key, a Git credential helper… This implies that only trusted tests are run to avoid credentials leaks (by having a Trojan test capturing these). - If the box is unchecked, the authentication information will be automatically shared with the execution environment.
Attention
Authentication information is still required for BDD test cases, even if it is not transmitted to the execution environment.
Set the committer's email address
The Commit Policy block allows you to enter the email address representing who commits into the remote repository. If this field is not filled in, an empty string will be used during the commit.
Add a repository
Focus
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 link automated scripts to test cases
- Keep Clone the repository locally on this server unchecked;
- Repository name: the name of a repository, it must match the name on the remote server since it is used to build the full URL of the repository (e.g.
https://www.github.com/Squash/my_repo
); - Branch: the branch containing the version of the automated tests to be executed.
Later on, to manually associate an automated script stored in the remote repository to a test case, use the three Squash Orchestrator fields. These ones are accessible on several screens as described here.
To transmit Gherkin or BDD test cases
- Check Clone the repository locally on this server;
- Repository name: the name of a repository, it must match the name on the remote server since it is used to build the full URL of the repository (e.g.
https://www.github.com/Squash/my_repo
); - Branch: the branch on which the
.feature
or.robot
scripts will be committed; - Path of the working directory: the path of the folder in which
.feature
or.robot
scripts will be written. This folder must already exist in the repository.
To finalize the configuration to transmit test cases, you must go to the project's configuration and associate a source code management server to it.
Learn more
To learn more about transmitting scripted test cases (Gherkin or BDD) written in Squash to a source code management server, go to the page transmit a scripted test case to a source code management server.
Delete a repository
Deleting a repository in Squash does neither delete the remote repository in the source code management server nor delete the local clone on the server hosting Squash.
Therefore, after deleting a repository in Squash administration, the local repository must also be deleted manually.