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 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 email 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

Afin de lier des scripts automatisés aux cas de test, il est nécessaire de déclarer le dépôt contenant ces tests.
Pour transmettre des cas de test Gherkin ou BDD écrits dans Squash à un dépôt distant, il est également nécessaire de cloner le dépôt sur le serveur hébergeant Squash et de configurer une authentification permettant à Squash d'écrire dans le dépôt distant. (Les dépôts locaux sont dans le répertoire défini par squash.path.local-git-repositories-folder.)

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 avoir à minima des droits de lecture sur le dépôt.
Dans le cas de cas de test Gherkin ou BDD à transmettre, il doit avoir de plus des droits d'écriture.

Vous avez la possibilité de choisir si vous souhaitez transmettre ou non ces informations d'authentification à un environnement d'exécution.

• Si la case [Ne pas partager] est cochée, les informations d'authentification ne seront pas transmises à un 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 email du commiter

Le bloc Politique de commit permet de renseigner l'adresse email représentant qui effectue le commit dans le dépôt distant. Si ce champ n'est pas renseigné, une chaîne de caractères vide sera utilisée lors du commit.

Ajouter un dépôt

Attention

Pour un serveur GitLab, si un "project token" ou un "group token" est utilisé, l'extension .git doit être ajoutée à la fin du nom du dépôt distant (exemple : depot01.git).

Pour lier des scripts automatisés aux cas de test

• Laisser Cloner le dépôt localement sur ce serveur décoché ;
• Nom du dépôt : le nom d'un dépôt, il doit correspondre au nom sur le serveur distant car il est utilisé pour construire l'URL complète du dépôt (par exemple https://www.github.com/Squash/mon_repo) ;
• Branche : la branche contenant la version des tests automatisés à exécuter.

Par la suite, pour associer manuellement un script automatisé stocké dans le dépôt distant à un cas de test, utilisez les trois champs de Squash Orchestrator.

Pour transmettre des cas de test Gherkin ou BDD

• Cocher Cloner le dépôt localement sur ce serveur ;
• Nom du dépôt : le nom d'un dépôt, il doit correspondre au nom sur le serveur distant car il est utilisé pour construire l'URL complète du dépôt (par exemple https://www.github.com/Squash/mon_repo) ;
• Branche : la branche sur laquelle les scripts .feature ou .robot seront commités ;
• Chemin du dossier de travail : le chemin du dossier dans lequel les scripts .feature ou .robot seront écrits. Ce dossier doit déjà exister dans le dépôt.

Pour finaliser la configuration pour transmettre des cas de test, vous devez aller dans la configuration du projet et associer un serveur de partage de code source.

En savoir plus

Pour en savoir plus sur la transmission de cas de test scriptés (Gherkin ou BDD) écrits dans Squash vers un serveur de gestion du code source, consultez la page transmettre un cas de test scripté vers un serveur de partage de code source.

Supprimer un dépôt

La suppression d'un dépôt dans Squash ne supprime ni le dépôt distant sur le serveur de gestion du code source, ni le clone local sur le serveur hébergeant Squash.
Par conséquent, après avoir supprimé un dépôt dans l'administration de Squash, le dépôt local doit également être supprimé manuellement.