Quelque chose pour rien ou Comment faire en sorte que Github exécute vos tests unitaires UnitTests

Salut les développeurs !

Voici encore un court message qui a pour but de simplifier la vie des développeurs. Nous allons maintenant vous expliquer comment faire en sorte que GitHub exécute des tests unitaires à chaque poussée vers le référentiel en ajoutant un seul fichier au référentiel. Gratuitement. Dans le nuage de Github. Ça a l'air génial, n'est-ce pas ?

C'est possible et très facile à faire. Le mérite revient à @Dmitry Maslennikov (et son référentiel), gestionnaire de paquets "ZPM Package Manager", et aux GitHub Actions.  Voyons comment tout cela fonctionne !

Considérons d'abord un référentiel avec des tests, par exemple le modèle IRIS de base. 

Supposons également que vous chargez votre code de développement dans le docker IRIS à l'aide de ZPM. Si ce n'est pas le cas, regardez la video sur la façon de le faire. 

Dans ce référentiel particulier, il s'agit de la ligne suivante et avec la présence de module.xml:

zpm "load /home/irisowner/irisbuild/ -v":1:1

Ensuite, ajoutons un scénario de GitHub Actions qui permettra de construire l'image et d'exécuter les tests :

name: unittest

on:
  push:
    branches:
      - maître
      - principale
  pull_request:
    branches:
      - maître
      - principale
  version:
    types:
      - libéré

tâches:
  build:
    runs-on: ubuntu-latest
    étapes:
      - utilisations: actions/checkout@v2
      - nom: Build and Test
        utilisations: docker/build-push-action@v2
        avec:
          contexte: .
          push: faux
          charge: vrai
          balises: ${{ github.repository }}:${{ github.sha }}
          build-args: TESTS=1

Ce scénario construit une image docker en utilisant Dockerfile du référentiel à chaque push ou pull-request vers la branche master ou main.

Voici une ligne supplémentaire qui transfère la variable TESTS=1 au Dockerfile :

build-args: TESTS=1

Cet argument est évaué dans le Dockerfile et si TESTS=1, il exécute les tests du paquet zpm du référentiel :

    ([ $TESTS -eq 0 ] || iris session iris -U $NAMESPACE "##class(%ZPM.PackageManager).Shell(\"test $MODULE -v -only\",1,1)") && \

Cette ligne vérifie le paramètre $TESTS et s'il n'est pas égal à 0, elle ouvre la session iris dans $NAMESPACE (IRISAPP dans ce cas) et exécute la commande ZPM :

test $MODULE -v -only

L'indicateur -only exécute uniquement le test sans charger le module (car il a été chargé auparavant dans le scénario de construction de docker).

Le nom du module est défini via $MODULE="dc-sample-template" dans ce cas :

ARG MODULE="dc-sample-template"

La commande va exécuter tous les unittests que nous avons mentionnés dans le module ZPM. Dans ce cas, nous le présentons avec cette ligne:

<UnitTest Name="/tests" Package="dc.sample.unittests" Phase="test"/>

ce qui signifie que les tests unitaires sont situés dans le dossier /tests du référentiel et que la ressource est dc.sample.unittests paquet de classe qui a deux classes.

Ce scénario va construire l'image de votre dépôt sur le nuage GitHub et exécuter des tests pour chaque push ou pull request vers la branche maître !

Voyons comment cela fonctionne !

La méthode Test42 prévoit que la méthode dc.sample.ObjectScript).Test() renvoie 42.

Changeons la ligne en 43 et envoyons pull-request. Nous pouvons voir (dans la section Actions ) que la pull-request a initié l'action Github. En effet, la construction a échoué :

Et les détails de la phase indiquent que Test42() a échoué sur AssertEquals 42 =43 :

Github envoie également des notifications par courriel en cas d'échec des constructions CI.

Remarque : pour exécuter les tests localement, il suffit d'appeler :

USER>zpm test "module-name"

Et si nous remettons la valeur de la variable à 42, les tests seront OK !

Et s'il s'agit de Pull-Request, vous pouvez voir le résultat de l'IC dans la section spéciale de contrôle Checks:

Et voilà !

Pour résumer, faire fonctionner GitHub (gratuitement !) pour les constructions de dockers et les unittests des projets InterSystems IRIS sur les pushes ou les pull-requests nécessite un scénario CI Github Actions scenario, qui sera le même pour chaque projet, et trois lignes dans le Dockerfile :

Le nom ZPM $MODULE - ceci doit être mis à jour avec chaque projet,

Le paramètre $TEST,

et la ligne RUN TEST.

Et utilisez le gestionnaire ZPM Package Manager!

Les commentaires et les réactions sont les bienvenus, et bon codage !

L'image du titre est liée à l'histoire de l'un de mes auteurs de SF préférés, Robert Sheckley, ["Quelque chose pour rien"] (https://en.wikipedia.org/wiki/Something_for_Nothing(book)) - la voici en [audio aussi] (https://www.youtube.com/watch?v=CL0GQTtx-5A), profitez-en !_