13 - Link Squash TM - Source Code Management Server

13.1 Configuring source code management servers

The management of the source code management servers is accessible from the Administration workspace by the button [</>].

This workspace is only useful when the automation workflow is enabled for at least one project.

Adding a source code management server

In 1.19, only 'git' type servers are compatible.

To add a source code management server:

1. From the Source Code Management Servers page, click on the [Add] button

2. A popup "Add a new source code management server" opens. Fill in the fields and click on [Add]:

a. Name: server name

b. Type: server type

c. Url: The server URL must match the base URL of the repositories it will contain. It can contain a group or user name. For example, if the user 'Squash' has repositories on the site 'github.com', the URL will be 'https://github.com/Squash'

Configuring a source code management server

After adding the source code management server, click on its name. A Source Code Management Server Configuration page is displayed.

This page contains:

• A [Back] button to return to the list of source code management servers

• A [Rename] button to rename the source code management server

• Five Blocks: Server Information, Authentication Protocol, Authentication Policy, Commit policy, Repositories

Authentication

Authentication with the source code management server is done from the Authentication Policy block via two "Login" and "Password" fields.

These are the identifiers that will allow Squash TM to authenticate with the source code management server when transmitting test cases to be automated (according to the automation workflow).

warning, to be able to add a repository, it is essential to have entered valid identifiers.

Commit policy

The Commit Policy block allows to precise the commiter's email address. If this field is empty this value is replaced by an empty character chain during the commit.

Add / Edit / Delete a repository

• • Add a repository

Prerequisites: Entering identifiers in the Authentication Policy block

1. In the repository block, click on the [Add] button

2. A popup "Add a new repository " opens with the following fields:

• Remote repository name (Required): The name of a repository must match its name on the remote server because it will be used to reach the full repository URL (for example: https://wwwgithub.com/username/ repositoryname )

• Work Branch (Required): The work branch is the branch on which files will be pushed to the remote repository. This branch must exist in the repository.

• Local repository path (required): the " repository" path is the path of the "local repository" that will be copied to the local server. If the path directories do not exist, they will be created by Squash TM. The target directory may already exist, but in this case, it must be empty

• Working folder path (optional): the working folder is the folder path relative to the " repository path" in which the .feature files will be written. If this field is completed, the file must already exist in the repository.

3. Complete the fields of the popup, click on [Add] or [Add another] if you intend to add more, then validate by clicking on [Confirm]

• • Modify a repository

Only the branch of work can be modified once the repository is added in Squash.

For that :

1. Click on the name of the branch in the repository block

2. In the popup, enter the name of another existing branch on the remote repository

3. Click on [Confirm]

• • Delete a repository

To delete a repository:

1. Click on the button [Delete] at the end of the repository line or select one or more lines in the table and click on [Delete].

2. Click on the [Confirm] button.

Warning, deleting a repository in Squash TM will not delete it in the source code management server.

FOCUS

The repository path must be absolute. The target directory and all non-existing subdirectories will be created by Squash TM.

The working folder path must be relative. The working folder as well as any non-existing subdirectories will be created by Squash.

FOCUS

The local repository is a directory that should not be deleted or modified by a third party 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 (ie, not a temporary folder).

13.2 Principle and operation of squash TM link - Source code management server

Adding a repository

When a user presses [Add] on the repositories page, the following actions are performed:

• 1. Checking for the identifiers existence : identifiers must have been entered in the block Authentication policy

  2. Check the validity of the target directory corresponding to the "repository path":

     1. • Check that the entered path is syntactically valid (that it contains no forbidden characters)

        • Check that directory does not exist, or if it exists that it is empty and that it is indeed a directory (and not of a file of the same name)

  3. The remote repository corresponding to the URL <Url Server> / <repository name> is cloned (git clone command): the target directory "repository path" and all subdirectories are created if they. did not exist; the contents of the remote repository and a hidden ".git" folder are then created in this directory

  4. Creating the working folder:

     1. • Check that the folder corresponding to the path "repository path" / " working folder " exists. If it is not, Squash TM creates it (as well as any non-existing subfolders)

The step of adding a repository therefore implies some conditions:

• • Url <Url Server> / <repository name> must be a valid remote git repository

  • The remote repository on this Url must not be an empty repository (it must have at least one commit)

  • Squash TM must be able to access the given Url

  • Valid identifiers for the affected server must have been entered

  • If the target directory "repository path" does not exist before creation, Squash TM must have write permissions in the parent directory to this directory

  • Squash TM must have write permissions in the target directory and its subfolders

Changing the branch of work

When a user confirms the change of the work branch, the following actions are performed:

1. check the local repository:

• Check that the directory located at the "depot way" still exists

• Check that this directory corresponds to a deposit

2. The contents of the git index is committed (command git commit) on the old branch if gherkin files are in progress of transmission:

At the time of the change of branch, it is possible that some test cases are waiting for transmission on the old branch (if a user "transmitted" test cases less than a minute ago. cf section test cases transmission ").
In order not to lose these changes, the timer is canceled and the commit / push of transmission is done directly on the old branch. The commit message is then "Commit of remaining non-committed files."

3. The branch of the local repository is modified (git checkout command):

In this way the next transmissions of test cases will be made on the new branch
- The target branch must exist on the remote repository

4. The commits history of this new branch is retrieved from the remote repository and the local repository is updated at the last revision (commands git fetch then git rebase)

5. Creating the working folder:

Check that the folder corresponding to the path "repository path" / "path of the working folder" exists. If not, Squash TM creates it (as well as any non-existing subfolders)

All of these steps imply that:

• • The identifiers for the concerned server are defined and valid

  • Squash TM can access the Url of the remote repository

  • Squash TM has the write permissions to the directory "repository path" and its subfolders

  • The new branch exists in the remote repository

Transmitting test cases

When a user transmits ([Transmit] button) Gherkin test cases as part of the automation workflow, the following actions are performed:

A. Writing files in the local repository:

SquashTM will write the gherkin files corresponding to the selected test cases to the root of the "working folder" of the local repository by naming them <id_ct>_<name_ct>.feature. If the final name (with the extension) exceeds 100 characters, it will be truncated to 100 characters long (with the extension).

Only gherkin test cases will be taken into account

B. Transmission of files to remote repository:

1. Verification of the local repository

2. The set of added / modified files contained in the folder "working folder" is added to the index git (command git add)

3. A timer is triggered by Squash TM at the end of which will be made a commit (command git commit) followed by a push (command git push). A rebase (commands git fetch then git rebase) is done if necessary

4. Any transmission made on this repository during the wait minute will reset the timer and add the new files to the git index (step 2)

All of these steps imply that:

• • The identifiers for the concerned server are defined and valid

  • SquashTM can access the Url of the remote repository

  • SquashTM has the write permission to the directory "repository path" and its subfolders