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
