Gérer les serveurs de partage de code source

Squash TM permet de lier des scripts automatisés à des cas de test et de transmettre des cas de test aux formats Gherkin ou BDD rédigés dans Squash TM sur un dépôt distant GitHub ou GitLab. La configuration de ces serveurs de partage de code source se gère depuis la page Serveurs>Serveurs de partage de code source de l'administration.

Attention

Pour accéder à la configuration d'un serveur de partage de code source, il faut avoir au préalable installé le plugin freeware Git.

Ajouter, modifier, supprimer un serveur de partage de code source

Depuis le tableau de gestion des serveurs de partage de code source, il est possible d'ajouter ou de supprimer des serveurs de façon unitaire ou en masse.

Lors de la création d'un serveur, il faut renseigner les champs Nom, Type et URL. Le nom du serveur est libre. L'URL du serveur doit correspondre à l'URL de base des dépôts qu'il contiendra. Il peut contenir un nom de groupe ou d'utilisateur. Par exemple, si l'utilisateur Squash possède des dépôts sur le site github.com, l'URL à renseigner est https://github.com/Squash.

Pour créer plusieurs serveurs à la suite, il suffit de cliquer sur le bouton [Ajouter un autre].

En cliquant sur le numéro de ligne # ou le Nom d'un serveur, sa page de consultation s'affiche permettant sa configuration complète.

Depuis la page de consultation d'un serveur de partage de code source, plusieurs actions sont possibles :

• modifier le Nom ou l'URL du serveur ;
• définir un protocole d'authentification ;
• renseigner les identifiants de connexion ;
• renseigner l'adresse mail du commiter ;
• ajouter ou supprimer des dépôts ;
• supprimer le serveur de partage de code source depuis le bouton [...].

Paramétrer un serveur de partage de code source

Pour utiliser un serveur pour transmettre des cas de test scriptés ou lier des scripts automatisés à des cas de test, il faut déclarer des dépôts sur le serveur. Les dépôts doivent être clonés dans le cadre de transmissions de scripts depuis Squash TM. Il est nécessaire dans ce cas de définir une authentification pour permettre à Squash de se connecter et d'écrire sur les dépôts distants.

Configurer l'authentification au serveur

L'authentification auprès du serveur de partage de code source est gérée par les blocs Protocole d'authentification et Politique d'authentification.

Dans le cas d'un serveur GitHub, il faut choisir le protocole "basic authentication" et renseigner dans le champ Login le login de l'utilisateur et dans le champ Mot de passe un personal access token généré au préalable depuis la section Settings>Developer settings>Personal access tokens de GitHub.

Dans le cas d'un serveur GitLab, il existe plusieurs types de token :

• pour un personal access token ou un impersonation token, choisir le protocole "basic authentication" et renseigner dans le champ Login le login de l'utilisateur et dans le champ Mot de passe le token ;
• pour les autres types de token, choisir le protocole "token authentification" et renseigner le token dans le champ Jeton.

Le token renseigné doit embarquer à minima des droits d'écriture sur les dépôts pour pouvoir cloner les dépôts et transmettre des cas de test scriptés.

Vous avez la possibilité de choisir si vous souhaitez transmettre ou non les informations d'authentification ("basic authentication" ou "token authentification") à l'environnement d'exécution.

• Si la case [Ne pas partager] est cochée, les informations d'authentification ne seront pas transmises à l'environnement d'exécution.
  Cela signifie que, lors de l'exécution des tests, les identifiants doivent déjà être configurés dans cet environnement, par exemple en utilisant une clé SSH, un "credential helper" Git… Cela implique que seuls des tests de confiance sont exécutés pour éviter les fuites d'identifiants (comme un test malveillant qui capturerait ces informations).
• Si la case est décochée, les informations d'authentification seront automatiquement partagées avec l'environnement d'exécution.

Attention

Les informations d'authentification restent nécessaires pour les cas de test BDD même si elles ne sont pas transmises à l'environnement d'exécution.

Renseigner l'adresse mail du commiter

Le bloc Politique de commit permet de renseigner l'adresse email de l'utilisateur Squash qui effectue le commit dans le dépôt distant. Si ce champ n'est pas renseigné cette valeur est remplacée par une chaîne de caractères vide lors du commit.

Ajouter/Modifier/Supprimer un dépôt

Pour transmettre des cas de test Gherkin ou BDD rédigés dans Squash TM vers un dépôt distant, il est nécessaire de cloner le dépôt sur le serveur hébergeant Squash. Pour ce faire, il faut enregistrer le dépôt depuis le bloc Dépôts en cochant bien la case Cloner le dépôt :

• Nom du dépôt distant (obligatoire) : le nom d'un dépôt doit correspondre à son nom sur le serveur distant car il est utilisé pour atteindre l'URL complète du dépôt (par exemple : https://www.github.com/nomUtilisateur/nomDépôt) ;
• Branche de travail (obligatoire) : la branche de travail est la branche sur laquelle seront poussés les fichiers sur le dépôt distant. Cette branche doit impérativement exister dans le dépôt ;
• Chemin du dépôt local (obligatoire) : le chemin du dépôt est le chemin du dépôt local qui sera copié sur le serveur local hébergeant Squash TM. Si les répertoires du chemin n'existent pas, ils seront créés par Squash TM. Le répertoire cible peut déjà exister mais dans ce cas, il doit être vide. Le dépôt local est un répertoire qui ne doit pas être supprimé ou modifié par un tiers pour assurer le bon fonctionnement dans Squash TM. Il est préférable de réserver un dossier sur la machine locale pour les dépôts de Squash, et s'assurer que ce dossier est stable (non un dossier temporaire) ;
• Chemin du dossier de travail (facultatif) : le dossier de travail est le chemin du dossier relatif au "chemin de dépôt" dans lequel les fichiers .feature ou . robot seront écrits. Si ce champ est complété, le dossier doit déjà exister dans le dépôt. (Attention : ce chemin ne doit pas commencer par /).

Focus

Dans le cas d'un serveur GitLab, si un "project token" ou "group token" est utilisé, il faut ajouter l'extension .git à la fin du nom du dépôt distant (ex : depot01.git).

Pour finaliser la configuration d'un dépôt créé pour transmettre des cas de test scriptés, il faut se rendre au niveau de la configuration d'un projet : Associer un serveur de partage de code source à un projet.

Pour associer manuellement un script automatisé stocké dans un dépôt distant à un cas de test présent dans Squash TM avec les trois champs Squash Orchestrator, il n'est pas nécessaire de cloner le dépôt qui contient le script. Il suffit de renseigner le nom du dépôt, le nom de la branche et de décocher la case 'Cloner le dépôt' lors de l'ajout du dépôt.

Suite à l'enregistrement d'un dépôt, seule la branche de travail peut être modifiée. Après vérification de l'existence de la branche sur le dépôt distant, l'historique des commits de cette nouvelle branche est récupéré depuis le dépôt distant et le dépôt local est mis à jour à la dernière révision.

La suppression d'un dépôt dans Squash TM ne le supprime pas dans le serveur de gestion de code source. Le clone du dépôt présent en local sur le serveur n'est pas non plus supprimé. Par conséquent, suite à la suppression d'un dépôt dans l'administration de Squash TM, il faut également supprimer le dépôt local sur le serveur pour supprimer définitivement le clone.

En savoir plus

Pour en savoir plus sur la transmission de cas de test scriptés (Gherkin ou BDD) rédigés dans Squash TM vers un serveur de partage de code source, consulter la page Transmettre un cas de test scripté sur un serveur de partage de code source.