Executer pytest dans un (des) containers

Bonjour,
Actuellement, je réalise les tests de mon application sur des vm (1 win server 2012 R2, 1 ubuntu 16.04, 1 ubuntu 18.04 et 1 centos7) avec Pytest lancé depuis un pipeline dans git.
J’aimerais passer à une infra en containers dans une optique de parallélisation des tests (étape suivante).
j’ai fait quelques recherches qui aboutissent pour la plupart à des posts sur stackoverflow qui sont bien trop précis par rapport à ce que je recherche.
Connaissez vous des articles ou des sites qui traitent de ce sujet?

Merci

Donne peut-être un peu plus de détails, parce que je ne vois pas quel est le problème :thinking:

La CI GitLab?

oui, il s’agit de la CI gitlab.
Mon problème c’est que je ne visualise pas comment cela va s’articuler:

  • que devient le runner?
  • J’ai fait un Dockerfile pour avoir un container (ubuntu 18.04) avec mon application déployée
  • est-ce que pytest va s’exécuter directement dans le container ou dans un autre?
  • est-ce que l’on peut créer dynamiquement plusieurs containers pour parallèliser les tests?

J’ai regardé les vidéos de Xavki mais je n’ai pas trouvé ce genre de réponse, ou alors j’ai pas bien compris les vidéos.
Je ne cherche pas forcément une réponse directe à mes questions mais plutôt des pistes pour orienter mes recherches et bien comprendre comment c’est sensé marcher

1 « J'aime »

Tes tests durent combien de temps ? C’est du E2E, du TU, du tests fonctionnels ?

Il s’agit de test d’intégration pour une appli qui fait du traitement de vidéo.
les tests peuvent durer de quelques secondes (vérifier la présence de la license) à 30 minutes (préparation de la vidéo, envoi à un service externe hébergé sur AWS, réception et analyse des résultats). La plupart des tests sont paramétrisés et utilisent des fixtures pour la création d’une license fictive ou d’un utilisateur pour le service externe. Les videos de test sont hébergés sur un serveur on premise.
Dans un premier temps, est ce qu’un docker compose avec un CMD /bin/bash suffit à remplacer la vm? Je me sens un peu perdu…

Tu peux très bien exécuter tes tests directement dans un conteneur de “test” et une fois que tes tests sont validés, faire une image finale sans les fichiers servant à réaliser les tests.

Ta pipeline devrait ressembler à :

  • creation image de test
  • execution des tests en parallele
  • création image finale (ou packaging de ton app puisque le but c’est juste d’utiliser des conteneurs pour faire des tests si je comprends bien)

Je fais rien de compliqué dans la CI de gitlab mais j’imagine que c’est possible d’attendre la fin et la validité des tests pour lancer la création de l’image finale (ou le packaging de ton app).

Pour la question, que devient le runner ? Le runner continue de vivre sa vie, tes conteneurs de tests en revanche sont éphémères sur environnement gitlab.
Si tes tests sont longs et que tu es chez gitlab.com, attention à ton quota de pipeline.

1 « J'aime »

Est-ce nécessaire de lancer des containers pour paralléliser les tests ? L’option -n de pytest permet de lancer des tests en parrallèle (cf Pytest - Run Tests in Parallel - Tutorialspoint )

Salut.

Je n’avais pas répondu avant car ne voyait pas le problème. Mais tu parles de tests d’intégration, la première question qui me vient est donc : les autres éléments sont ils accessibles ? Car sinon tu ne pourra pas vérifier ton test ? Ou alors faut il que tu build plusieurs éléments de ta stack pour faire ce test d’intégration ?

Après pour ton test si le reste de ta stack est accessible il te suffit dans ton projet git de prévoir les tests (ce que tu as déjà fait il me semble avec pytest), puis paramétrer ton gitlab-ci.yaml pour lancer les tests puis le build, puis éventuellement le push de l’image quelque part. Tout se paramètre dans le fichier yaml de gitlab-ci ou tu peux indiquer si un echec d’une étape provoque l’arret ou pas, si tu veux lancer en parallèle certaines actions (stages), etc…

Pour répondre a tes questions :

  • que devient le runner?
    Le runner gitlab ? Tu utilises gitlab.com ? le runner il faut en avoir un quelque part c’est lui qui réalise les actions de build, push, etc … Mais bon tu dois juste savoir qu’il t’en faut car c’est lui qui s’occupe de tout.

  • est-ce que pytest va s’exécuter directement dans le container ou dans un autre?
    Le runner s’occupe de tout, pour le test il va lancer un conteneur, lancer les tests puis supprimer le conteneur, tu ne gères rien la dedans (sauf dans la description du yaml gitlab-ci).

  • est-ce que l’on peut créer dynamiquement plusieurs containers pour parallèliser les tests?
    C’est dans le fichier yaml gitlab-ci que tu indiques le parallélisme des étapes (stages).

Exemple ici : GitLab CI: Run jobs sequentially, in parallel or build a custom pipeline | GitLab

Extrait : le pack-gz et pack-iso se lance en parallèle.


image: alpine

stages:
  - compile
  - test
  - package

compile:
  stage: compile
  script: cat file1.txt file2.txt > compiled.txt
  artifacts:
    paths:
    - compiled.txt
    expire_in: 20 minutes

test:
  stage: test
  script: cat compiled.txt | grep -q 'Hello world'

pack-gz:
  stage: package
  script: cat compiled.txt | gzip > packaged.gz
  artifacts:
    paths:
    - packaged.gz

pack-iso:
  stage: package
  before_script:
  - echo "ipv6" >> /etc/modules
  - apk update
  - apk add xorriso
  script:
  - mkisofs -o ./packaged.iso ./compiled.txt
  artifacts:
    paths:
    - packaged.iso

Voici un exemple d’un de mes projets qui lance le test puis le build (si le test est passé comme il faut) :

stages:
  - test
  - build

test:
  stage: test
  script:
    # Install packages
    - apk update && apk add git
    - apk add --no-cache python3
    - apk add --update python3-dev py-pip
    - pip3 install --upgrade pip setuptools
    - pip3 install -r requirements-test.txt
    # Launch Test
    - python3 manage.py test nom_de_mon_service
  only:
    - tags
  except:
    - master
    - qualification

build:
  stage: build
  script:
    # Login Gitlab.com
    # Todo : check password alert here https://docs.docker.com/engine/reference/commandline/login/#credentials-store
    - echo $CI_JOB_TOKEN | docker login -u gitlab-ci-token --password-stdin registry.gitlab.com
    # Build docker image with cache
    - docker pull $CONTAINER_IMAGE:latest || true
    - docker build --cache-from $CONTAINER_IMAGE:latest -t $CONTAINER_IMAGE:$CI_COMMIT_TAG -t $CONTAINER_IMAGE:latest . --label version=$LABEL_VERSION
    # Push to gitlab.com latest and tag branch
    - docker push $CONTAINER_IMAGE:$CI_COMMIT_TAG
    - docker push $CONTAINER_IMAGE:latest
    - docker logout registry.gitlab.com
  only:
    - tags
  except:
    - master
    - qualification

Et voici le lien vers la doc de gitlab-ci : qui répondra à toutes tes questions je pense : Get started with GitLab CI/CD | GitLab

1 « J'aime »