Cet article intĂ©ressera tant les testeurs que les dĂ©veloppeurs, mais il est principalement destinĂ© aux automatisateurs qui ont rencontrĂ© le problĂšme de configuration de GitLab CI/CD pour rĂ©aliser des tests d'intĂ©gration dans des environnements avec des ressources d'infrastructure insuffisantes et/ou en l'absence d'une plateforme d'orchestration de conteneurs. Je vais expliquer comment configurer le dĂ©ploiement des environnements de test Ă l'aide de docker compose sur un seul runner GitLab shell, de maniĂšre Ă ce que les services lancĂ©s lors du dĂ©ploiement de plusieurs environnements ne se gĂȘnent pas mutuellement.
Contenu
Prérequis
Dans ma pratique, il m'est souvent arrivĂ© de "rĂ©parer" les tests d'intĂ©gration sur les projets. Et souvent, le premier et le plus important problĂšme est le pipeline CI dans lequel les tests d'intĂ©gration du service(s) en cours de dĂ©veloppement est effectuĂ© dans un environnement dev/stage. Cela a causĂ© de nombreux problĂšmes : En raison de dĂ©fauts dans un service ou un autre, le circuit de test peut ĂȘtre corrompu par des donnĂ©es erronĂ©es lors des tests d'intĂ©gration. Il y a eu des cas oĂč l'envoi d'une requĂȘte avec un format JSON erronĂ© faisait planter le service, rendant l'ensemble du stand totalement non fonctionnel.
- Un ralentissement du circuit de test avec l'augmentation des donnĂ©es de test. Je pense qu'il n'est pas nĂ©cessaire de dĂ©crire un exemple avec le nettoyage/reversement de la base de donnĂ©es. Dans ma pratique, je n'ai pas rencontrĂ© de projet oĂč cette procĂ©dure se dĂ©roulait sans accroc.
- Le risque de compromettre le bon fonctionnement du circuit de test lors de l'évaluation des configurations communes du systÚme. Par exemple, user/group/password/application policy.
- Les donnĂ©es de test des tests automatisĂ©s gĂȘnent les testeurs manuels.
- Certains diront que de bons tests automatisés devraient nettoyer les données aprÚs leur exécution. J'ai des arguments contre cela :
Les environnements dynamiques sont trĂšs pratiques Ă utiliser.
- Tous les objets ne peuvent pas ĂȘtre supprimĂ©s du systĂšme via l'API. Par exemple, l'appel pour supprimer un objet n'est pas implĂ©mentĂ©, car il contredirait la logique mĂ©tier.
- Lors de la crĂ©ation d'un objet via l'API, un grand nombre de mĂ©tadonnĂ©es peuvent ĂȘtre gĂ©nĂ©rĂ©es, ce qui est problĂ©matique Ă supprimer.
- Si les tests ont des dĂ©pendances entre eux, le processus de nettoyage des donnĂ©es aprĂšs l'exĂ©cution des tests devient un vĂ©ritable casse-tĂȘte.
- Des appels supplémentaires (et, à mon avis, injustifiés) à l'API.
- Des appels supplémentaires (qui, à mon avis, ne sont pas justifiés) à l'API.
- Et le principal argument : lorsque les donnĂ©es de test commencent Ă ĂȘtre nettoyĂ©es directement Ă partir de la base de donnĂ©es. Cela se transforme en un vĂ©ritable cirque PK/FK ! Les dĂ©veloppeurs disent : « J'ai juste ajoutĂ©/supprimĂ©/renommĂ© une table, pourquoi 100500 tests d'intĂ©gration Ă©chouent-ils ? »
Ă mon avis, la solution la plus optimale est un environnement dynamique.
- Beaucoup utilisent docker-compose pour lancer un environnement de test, mais peu l'utilisent lors des tests d'intégration dans CI/CD. Et ici, je ne prends pas en compte Kubernetes, Swarm et d'autres plateformes d'orchestration de conteneurs. Elles ne sont pas présentes dans toutes les entreprises. Ce serait bien que le fichier docker-compose.yml soit universel.
- MĂȘme si nous avons notre propre runner QA, comment pouvons-nous faire en sorte que les services lancĂ©s via docker-compose ne se gĂȘnent pas ?
- Comment collecter les logs des services testés ?
- Comment nettoyer le runner ?
J'ai mon propre GitLab runner pour mes projets et j'ai rencontré ces questions lors du développement. pour . Plus précisément lors de l'exécution des tests d'intégration. C'est là que nous allons résoudre ces questions avec des exemples de ce projet.
GitLab Shell Runner
Pour le runner, je recommande une machine virtuelle Linux avec 4 vCPU, 4 Go de RAM, 50 Go de disque dur.
Il y a beaucoup d'informations sur Internet concernant la configuration de gitlab-runner, donc en bref :
- Connectez-vous Ă la machine via SSH
Si vous avez moins de 8 Go de RAM, je recommande , pour ne pas avoir de OOM killer qui tue nos tùches à cause d'un manque de RAM. Cela peut arriver lorsque plus de 5 tùches sont lancées simultanément. Les tùches prendront plus de temps, mais fonctionneront de maniÚre stable.
Exemple avec OOM killer
Si dans les logs de la tĂąche vous voyez
bash: line 82: 26474 Killed, exécutez simplement sur le runnersudo dmesg | grep 26474[26474] 1002 26474 1061935 123806 339 0 0 java Out of memory: Kill process 26474 (java) score 127 or sacrifice child Killed process 26474 (java) total-vm:4247740kB, anon-rss:495224kB, file-rss:0kB, shmem-rss:0kBEt si l'image ressemble à cela, alors soit ajoutez du swap, soit augmentez la RAM.
- Nous installons , , , make.
- Ajoutons l'utilisateur
gitlab-runnerau groupedockersudo groupadd docker sudo usermod -aG docker gitlab-runner - gitlab-runner.
Ouvrons pour édition
/etc/gitlab-runner/config.tomlet ajoutonsconcurrent=20 [[runners]] request_concurrency = 10Cela permettra d'exécuter des tùches parallÚles sur un seul runner. Lire plus en détail .
Si vous avez une machine plus puissante, par exemple 8 vCPU, 16 Go de RAM, ces chiffres peuvent ĂȘtre multipliĂ©s par au moins 2. Tout dĂ©pend de ce qui sera exĂ©cutĂ© prĂ©cisĂ©ment sur ce runner et en quelle quantitĂ©.
C'est suffisant.
Préparation de docker-compose.yml
La tùche principale est de créer un fichier docker-compose.yml universel que les développeurs/testeurs peuvent utiliser à la fois localement et dans le pipeline CI.
Tout d'abord, nous donnons des noms uniques aux services pour CI. L'une des variables uniques dans GitLab CI est la variable CI_JOB_ID. Si vous indiquez container_name avec la valeur "service-${CI_JOB_ID:-local}", alors dans le cas oĂč :
- si
CI_JOB_IDn'est pas définie dans les variables d'environnement,
le nom du service seraservice-local - si
CI_JOB_IDdéfinie dans les variables d'environnement (par exemple 123),
le nom du service seraservice-123
DeuxiÚmement, nous créons un réseau commun pour les services exécutés. Cela nous donne une isolation au niveau du réseau lors de l'exécution de plusieurs environnements de test.
networks:
default:
external:
name: service-network-${CI_JOB_ID:-local}C'est en fait le premier pas vers le succĂšs =)
Exemple de mon docker-compose.yml avec des commentaires
version: "3"
# Pour le bon fonctionnement de web (php) et fmt, il faut que les conteneurs aient un contenu exécutable commun.
# Dans notre cas, c'est le répertoire /var/www/testrail
volumes:
static-content:
# Isoler l'environnement au niveau du réseau
networks:
default:
external:
name: testrail-network-${CI_JOB_ID:-local}
services:
db:
image: mysql:5.7.22
# Chaque container_name contient ${CI_JOB_ID:-local}
container_name: "testrail-mysql-${CI_JOB_ID:-local}"
environment:
MYSQL_HOST: db
MYSQL_DATABASE: mydb
MYSQL_ROOT_PASSWORD: 1234
SKIP_GRANT_TABLES: 1
SKIP_NETWORKING: 1
SERVICE_TAGS: dev
SERVICE_NAME: mysql
networks:
- default
migration:
image: registry.gitlab.com/touchbit/image/testrail/migration:latest
container_name: "testrail-migration-${CI_JOB_ID:-local}"
links:
- db
depends_on:
- db
networks:
- default
fpm:
image: registry.gitlab.com/touchbit/image/testrail/fpm:latest
container_name: "testrail-fpm-${CI_JOB_ID:-local}"
volumes:
- static-content:/var/www/testrail
links:
- db
networks:
- default
web:
image: registry.gitlab.com/touchbit/image/testrail/web:latest
container_name: "testrail-web-${CI_JOB_ID:-local}"
# Si les variables TR_HTTP_PORT ou TR_HTTPS_PORT ne sont pas définies,
# alors le service se lĂšve sur le port 80 et 443 respectivement.
ports:
- ${TR_HTTP_PORT:-80}:80
- ${TR_HTTPS_PORT:-443}:443
volumes:
- static-content:/var/www/testrail
links:
- db
- fpm
networks:
- defaultExemple de lancement local
docker-compose -f docker-compose.yml up -d
Démarrage testrail-mysql-local ... fait
Démarrage testrail-migration-local ... fait
Démarrage testrail-fpm-local ... fait
Recréer testrail-web-local ... faitMais tout n'est pas si simple avec le lancement en CI.
Préparation de Makefile
J'utilise Makefile car c'est trĂšs pratique pour la gestion locale de l'environnement ainsi qu'en CI. Ensuite, les commentaires en ligne
# ĐŁ ĐŒĐ”ĐœŃ ĐČ ĐżŃĐŸĐ”ĐșŃаŃ
ĐČŃĐ” ĐČŃĐżĐŸĐŒĐŸĐłĐ°ŃДлŃĐœŃĐ” ĐČĐ”ŃĐž Đ»Đ”Đ¶Đ°Ń ĐČ ĐŽĐžŃĐ”ĐșŃĐŸŃОО `.indirect`,
# ĐČ ŃĐŸĐŒ ŃĐžŃлД Đž `docker-compose.yml`
# ĐŃĐżĐŸĐ»ŃĐ·ĐŸĐČаŃŃ bash Ń ĐŸĐżŃОДĐč pipefail
# pipefail - ŃĐ”ĐčĐ»ĐžŃ ĐČŃĐżĐŸĐ»ĐœĐ”ĐœĐžĐ” паĐčпа, Đ”ŃлО ĐșĐŸĐŒĐ°ĐœĐŽĐ° ĐČŃĐżĐŸĐ»ĐœĐžĐ»Đ°ŃŃ Ń ĐŸŃОбĐșĐŸĐč
SHELL=/bin/bash -o pipefail
# ĐŃŃĐ°ĐœĐ°ĐČлОĐČĐ°Đ”ĐŒ ĐșĐŸĐœŃĐ”ĐčĐœĐ”ŃŃ Đž ŃЎалŃĐ”ĐŒ ŃĐ”ŃŃ
docker-kill:
docker-compose -f $${CI_JOB_ID:-.indirect}/docker-compose.yml kill
docker network rm network-$${CI_JOB_ID:-testrail} || true
# ĐŃДЎĐČаŃĐžŃДлŃĐœĐŸ ĐČŃĐżĐŸĐ»ĐœŃĐ”ĐŒ docker-kill
docker-up: docker-kill
# ĐĄĐŸĐ·ĐŽĐ°Đ”ĐŒ ŃĐ”ŃŃ ĐŽĐ»Ń ĐŸĐșŃŃĐ¶Đ”ĐœĐžŃ
docker network create network-$${CI_JOB_ID:-testrail}
# ĐабОŃĐ°Đ”ĐŒ ĐżĐŸŃĐ»Đ”ĐŽĐœĐžĐ” ĐŸĐ±ŃĐ°Đ·Ń ĐžĐ· docker-registry
docker-compose -f $${CI_JOB_ID:-.indirect}/docker-compose.yml pull
# ĐапŃŃĐșĐ°Đ”ĐŒ ĐŸĐșŃŃĐ¶Đ”ĐœĐžĐ”
# force-recreate - ĐżŃĐžĐœŃĐŽĐžŃДлŃĐœĐŸĐ” пДŃĐ”ŃĐŸĐ·ĐŽĐ°ĐœĐžĐ” ĐșĐŸĐœŃĐ”ĐčĐœĐ”ŃĐŸĐČ
# renew-anon-volumes - ĐœĐ” ĐžŃĐżĐŸĐ»ŃĐ·ĐŸĐČаŃŃ volumes ĐżŃДЎŃĐŽŃŃĐžŃ
ĐșĐŸĐœŃĐ”ĐčĐœĐ”ŃĐŸĐČ
docker-compose -f $${CI_JOB_ID:-.indirect}/docker-compose.yml up --force-recreate --renew-anon-volumes -d
# ĐŃ Đž, ĐœĐ° ĐČŃŃĐșĐžĐč ŃĐ»ŃŃаĐč, ĐČŃĐČĐ”ŃŃĐž ŃŃĐŸ ŃĐ°ĐŒ Ń ĐœĐ°Ń ĐČ ĐżŃĐžĐœŃОпД запŃŃĐ”ĐœĐŸ ĐœĐ° ĐŒĐ°ŃĐžĐœĐșĐ”
docker ps
# ĐĐŸĐ»Đ»Đ”ĐșŃĐžĐŒ Đ»ĐŸĐłĐž ŃĐ”ŃĐČĐžŃĐŸĐČ
docker-logs:
mkdir ./logs || true
docker logs testrail-web-$${CI_JOB_ID:-local} >& logs/testrail-web.log
docker logs testrail-fpm-$${CI_JOB_ID:-local} >& logs/testrail-fpm.log
docker logs testrail-migration-$${CI_JOB_ID:-local} >& logs/testrail-migration.log
docker logs testrail-mysql-$${CI_JOB_ID:-local} >& logs/testrail-mysql.log
# ĐŃĐžŃŃĐșа ŃĐ°ĐœĐœĐ”Ńа
docker-clean:
@echo ĐŃŃĐ°ĐœĐ°ĐČлОĐČĐ°Đ”ĐŒ ĐČŃĐ” testrail-ĐșĐŸĐœŃĐ”ĐčĐœĐ”ŃŃ
docker kill $$(docker ps --filter=name=testrail -q) || true
@echo ĐŃĐžŃŃĐșа ĐŽĐŸĐșĐ”Ń ĐșĐŸĐœŃĐ”ĐčĐœĐ”ŃĐŸĐČ
docker rm -f $$(docker ps -a -f --filter=name=testrail status=exited -q) || true
@echo ĐŃĐžŃŃĐșа dangling ĐŸĐ±ŃĐ°Đ·ĐŸĐČ
docker rmi -f $$(docker images -f "dangling=true" -q) || true
@echo ĐŃĐžŃŃĐșа testrail ĐŸĐ±ŃĐ°Đ·ĐŸĐČ
docker rmi -f $$(docker images --filter=reference='registry.gitlab.com/touchbit/image/testrail/*' -q) || true
@echo ĐŃĐžŃŃĐșа ĐČŃĐ”Ń
ĐœĐ”ĐžŃĐżĐŸĐ»ŃĐ·ŃĐ”ĐŒŃŃ
volume
docker volume rm -f $$(docker volume ls -q) || true
@echo ĐŃĐžŃŃĐșа ĐČŃĐ”Ń
testrail ŃĐ”ŃĐ”Đč
docker network rm $(docker network ls --filter=name=testrail -q) || true
docker ps
Vérification
make docker-up
$ make docker-up
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml kill
Killing testrail-web-local ... done
Killing testrail-fpm-local ... done
Killing testrail-mysql-local ... done
docker network rm network-${CI_JOB_ID:-testrail} || true
network-testrail
docker network create network-${CI_JOB_ID:-testrail}
d2ec063324081c8bbc1b08fd92242c2ea59d70cf4025fab8efcbc5c6360f083f
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml pull
Pulling db ... done
Pulling migration ... done
Pulling fpm ... done
Pulling web ... done
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Recreating testrail-mysql-local ... done
Recreating testrail-fpm-local ... done
Recreating testrail-migration-local ... done
Recreating testrail-web-local ... done
docker ps
CONTAINER ID PORTS NAMES
a845d3cb0e5a 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp testrail-web-local
19d8ef001398 9000/tcp testrail-fpm-local
e28840a2369c 3306/tcp, 33060/tcp testrail-migration-local
0e7900c23f37 3306/tcp testrail-mysql-local
make docker-logs
$ make docker-logs
mkdir .\/logs || true
mkdir: cannot create directory â.\/logsâ: File exists
docker logs testrail-web-${CI_JOB_ID:-local} >& logs\/testrail-web.log
docker logs testrail-fpm-${CI_JOB_ID:-local} >& logs\/testrail-fpm.log
docker logs testrail-migration-${CI_JOB_ID:-local} >& logs\/testrail-migration.log
docker logs testrail-mysql-${CI_JOB_ID:-local} >& logs\/testrail-mysql.log
Préparation de .gitlab-ci.yml
Lancement des tests d'intégration
Intégration:
étape: test
tags:
- my-shell-runner
before_script:
# Authentification dans le registre
- docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
# Génération des ports TR_HTTP_PORT et TR_HTTPS_PORT pseudo-uniques
- export TR_HTTP_PORT=$(shuf -i10000-60000 -n1)
- export TR_HTTPS_PORT=$(shuf -i10000-60000 -n1)
# Création d'un répertoire avec l'identifiant de la tùche
- mkdir ${CI_JOB_ID}
# Copie de notre docker-compose.yml dans le répertoire créé
# afin que le contexte soit différent pour chaque tùche
- cp .indirect\/docker-compose.yml ${CI_JOB_ID}\/docker-compose.yml
script:
# Mise en place de notre environnement
- make docker-up
# Exécution des tests avec jar exécutable (c'est comme cela que je fonctionne)
- java -jar itest.jar --http-port ${TR_HTTP_PORT} --https-port ${TR_HTTPS_PORT}
# ou dans le conteneur
- docker run --network=testrail-network-${CI_JOB_ID:-local} --rm itest
after_script:
# Récupération des logs
- make docker-logs
# ArrĂȘt de l'environnement
- make docker-kill
artifacts:
# Sauvegarde des logs
when: always
paths:
- logs
expire_in: 30 daysEn conséquence de l'exécution d'une telle tùche, le répertoire logs des artefacts contiendra les logs des services et des tests. Ce qui est trÚs pratique en cas d'erreurs. Chaque test en parallÚle écrit son propre log, mais j'en parlerai séparément.

Nettoyage du runner
La tùche ne sera exécutée que selon un calendrier.
stages:
- clean
- build
- test
Nettoyage:
étape: clean
only:
- schedules
tags:
- my-shell-runner
script:
- make docker-cleanEnsuite, allons dans notre projet GitLab -> CI/CD -> Schedules -> New Schedule et ajoutons un nouvel emploi du temps
Résultat
Nous lançons 4 tùches dans GitLab CI
Dans les journaux de la derniÚre tùche avec les tests d'intégration, nous voyons des conteneurs de différentes tùches
IDENTIFIANT DU CONTENEUR NOMS
c6b76f9135ed testrail-web-204645172
01d303262d8e testrail-fpm-204645172
2cdab1edbf6a testrail-migration-204645172
826aaf7c0a29 testrail-mysql-204645172
6dbb3fae0322 testrail-web-204645084
3540f8d448ce testrail-fpm-204645084
70fea72aa10d testrail-mysql-204645084
d8aa24b2892d testrail-web-204644881
6d4ccd910fad testrail-fpm-204644881
685d8023a3ec testrail-mysql-204644881
1cdfc692003a testrail-web-204644793
6f26dfb2683e testrail-fpm-204644793
029e16b26201 testrail-mysql-204644793
c10443222ac6 testrail-web-204567103
04339229397e testrail-fpm-204567103
6ae0accab28d testrail-mysql-204567103
b66b60d79e43 testrail-web-204553690
033b1f46afa9 testrail-fpm-204553690
a8879c5ef941 testrail-mysql-204553690
069954ba6010 testrail-web-204553539
ed6b17d911a5 testrail-fpm-204553539
1a1eed057ea0 testrail-mysql-204553539Journal plus détaillé
$ docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
AVERTISSEMENT ! Utiliser --password via la CLI n'est pas sécurisé. Utilisez --password-stdin.
AVERTISSEMENT ! Votre mot de passe sera stocké en texte clair dans /home/gitlab-runner/.docker/config.json.
Configurez un assistant d'identification pour supprimer cet avertissement. Voir
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Connexion réussie
$ export TR_HTTP_PORT=$(shuf -i10000-60000 -n1)
$ export TR_HTTPS_PORT=$(shuf -i10000-60000 -n1)
$ mkdir ${CI_JOB_ID}
$ cp .indirect/docker-compose.yml ${CI_JOB_ID}/docker-compose.yml
$ make docker-up
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml kill
docker network rm testrail-network-${CI_JOB_ID:-local} || true
Erreur : Pas de tel réseau : testrail-network-204645172
docker network create testrail-network-${CI_JOB_ID:-local}
0a59552b4464b8ab484de6ae5054f3d5752902910bacb0a7b5eca698766d0331
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml pull
Tirage de web ... fait
Tirage de fpm ... fait
Tirage de migration ... fait
Tirage de db ... fait
docker-compose -f ${CI_JOB_ID:-.indirect}/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Création du volume "204645172_static-content" avec le pilote par défaut
Création de testrail-mysql-204645172 ...
Création de testrail-mysql-204645172 ... terminé
Création de testrail-migration-204645172 ... terminé
Création de testrail-fpm-204645172 ... terminé
Création de testrail-web-204645172 ... terminé
docker ps
ID CONTENEUR IMAGE COMMANDE CRĂĂ ĂTAT PORTS NOMS
c6b76f9135ed registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon deâŠ" Il y a 13 secondes En ligne 1 seconde 0.0.0.0:51148->80/tcp, 0.0.0.0:25426->443/tcp testrail-web-204645172
01d303262d8e registry.gitlab.com/touchbit/image/testrail/fpm:latest "docker-php-entrypoiâŠ" Il y a 16 secondes En ligne 13 secondes 9000/tcp testrail-fpm-204645172
2cdab1edbf6a registry.gitlab.com/touchbit/image/testrail/migration:latest "docker-entrypoint.sâŠ" Il y a 16 secondes En ligne 13 secondes 3306/tcp, 33060/tcp testrail-migration-204645172
826aaf7c0a29 mysql:5.7.22 "docker-entrypoint.sâŠ" Il y a 18 secondes En ligne 16 secondes 3306/tcp testrail-mysql-204645172
6dbb3fae0322 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon deâŠ" Il y a 36 secondes En ligne 22 secondes 0.0.0.0:44202->80/tcp, 0.0.0.0:20151->443/tcp testrail-web-204645084
3540f8d448ce registry.gitlab.com/touchbit/image/testrail/fpm:latest "docker-php-entrypoiâŠ" Il y a 38 secondes En ligne 35 secondes 9000/tcp testrail-fpm-204645084
70fea72aa10d mysql:5.7.22 "docker-entrypoint.sâŠ" Il y a 40 secondes En ligne 37 secondes 3306/tcp testrail-mysql-204645084
d8aa24b2892d registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon deâŠ" Il y a environ une minute En ligne 53 secondes 0.0.0.0:31103->80/tcp, 0.0.0.0:43872->443/tcp testrail-web-204644881
6d4ccd910fad registry.gitlab.com/touchbit/image/testrail/fpm:latest "docker-php-entrypoiâŠ" Il y a environ une minute En ligne environ une minute 9000/tcp testrail-fpm-204644881
685d8023a3ec mysql:5.7.22 "docker-entrypoint.sâŠ" Il y a environ une minute En ligne environ une minute 3306/tcp testrail-mysql-204644881
1cdfc692003a registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon deâŠ" Il y a environ une minute En ligne environ une minute 0.0.0.0:44752->80/tcp, 0.0.0.0:23540->443/tcp testrail-web-204644793
6f26dfb2683e registry.gitlab.com/touchbit/image/testrail/fpm:latest "docker-php-entrypoiâŠ" Il y a environ une minute En ligne environ une minute 9000/tcp testrail-fpm-204644793
029e16b26201 mysql:5.7.22 "docker-entrypoint.sâŠ" Il y a environ une minute En ligne environ une minute 3306/tcp testrail-mysql-204644793
c10443222ac6 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon deâŠ" Il y a 5 heures En ligne 5 heures 0.0.0.0:57123->80/tcp, 0.0.0.0:31657->443/tcp testrail-web-204567103
04339229397e registry.gitlab.com/touchbit/image/testrail/fpm:latest "docker-php-entrypoiâŠ" Il y a 5 heures En ligne 5 heures 9000/tcp testrail-fpm-204567103
6ae0accab28d mysql:5.7.22 "docker-entrypoint.sâŠ" Il y a 5 heures En ligne 5 heures 3306/tcp testrail-mysql-204567103
b66b60d79e43 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon deâŠ" Il y a 5 heures En ligne 5 heures 0.0.0.0:56321->80/tcp, 0.0.0.0:58749->443/tcp testrail-web-204553690
033b1f46afa9 registry.gitlab.com/touchbit/image/testrail/fpm:latest "docker-php-entrypoiâŠ" Il y a 5 heures En ligne 5 heures 9000/tcp testrail-fpm-204553690
a8879c5ef941 mysql:5.7.22 "docker-entrypoint.sâŠ" Il y a 5 heures En ligne 5 heures 3306/tcp testrail-mysql-204553690
069954ba6010 registry.gitlab.com/touchbit/image/testrail/web:latest "nginx -g 'daemon deâŠ" Il y a 5 heures En ligne 5 heures 0.0.0.0:32869->80/tcp, 0.0.0.0:16066->443/tcp testrail-web-204553539
ed6b17d911a5 registry.gitlab.com/touchbit/image/testrail/fpm:latest "docker-php-entrypoiâŠ" Il y a 5 heures En ligne 5 heures 9000/tcp testrail-fpm-204553539
1a1eed057ea0 mysql:5.7.22 "docker-entrypoint.sâŠ" Il y a 5 heures En ligne 5 heures 3306/tcp testrail-mysql-204553539Toutes les tĂąches ont Ă©tĂ© terminĂ©es avec succĂšs
Les artefacts de la tĂąche contiennent les journaux des services et des tests
Tout semble en ordre, mais il y a un dĂ©tail. Le pipeline peut ĂȘtre annulĂ© de force pendant l'exĂ©cution des tests d'intĂ©gration, et dans ce cas, les conteneurs lancĂ©s ne seront pas arrĂȘtĂ©s. Il est parfois nĂ©cessaire de nettoyer le runner. Malheureusement, la tĂąche de mise Ă jour dans GitLab CE est toujours en statut.
Mais nous avons ajouté l'exécution de la tùche selon un calendrier, et personne ne nous interdit de la lancer manuellement.
Passons à notre projet -> CI/CD -> Schedules et lançons la tùche Nettoyer le runner
Total :
- Nous avons un runner shell.
- Il n'y a pas de conflits entre les tĂąches et l'environnement.
- Nous avons un lancement parallÚle de tùches avec les tests d'intégration.
- Les tests d'intĂ©gration peuvent ĂȘtre lancĂ©s Ă la fois localement et dans un conteneur.
- Les journaux des services et des tests sont collectés et attachés à la tùche du pipeline.
- Il est possible de nettoyer le runner des anciennes images docker.
Le temps de configuration â ~2 heures.
VoilĂ , c'est Ă peu prĂšs tout. Je serais ravi d'avoir vos retours.
Source : habr.com
