Dieser Artikel wird sowohl für Tester als auch für Entwickler von Interesse sein, richtet sich jedoch in erster Linie an Automatisierer, die auf das Problem gestoßen sind, GitLab CI/CD für die Durchführung von Integrationstests unter Bedingungen unzureichender Infrastrukturressourcen und/oder fehlender Container-Orchestrierungsplattformen einzurichten. Ich werde erklären, wie man die Bereitstellung von Testumgebungen mit Docker Compose auf einem einzigen GitLab Shell Runner einrichtet, sodass sich beim Bereitstellen mehrerer Umgebungen die gestarteten Services nicht gegenseitig behindern.
Inhalt
Vorbedingungen
In meiner Praxis kam es oft vor, dass ich das Integrationstestverfahren in Projekten "heilen" musste. Und oft ist das erste und wichtigste Problem der CI-Pipeline, in der die Integrationstests des entwickelten Services/der Services im dev/stage Umfeld durchgeführt werden. Dies führte zu zahlreichen Problemen:
- Aufgrund von Defekten in einem oder mehreren Services kann der Testkreis während der Integrationstests durch fehlerhafte Daten beeinträchtigt werden. Es gab Fälle, in denen das Senden einer Anfrage mit einem fehlerhaften JSON-Format den Service zum Absturz brachte, was den Stand vollständig außer Betrieb setzte.
- Verlangsamung des Testkreislaufs mit zunehmenden Testdaten. Ich denke, es macht keinen Sinn, ein Beispiel für die Bereinigung/Rückführung der Datenbank zu beschreiben. In meiner Praxis habe ich noch nie ein Projekt erlebt, in dem dieser Prozess reibungslos verlief.
- Risiko, die Funktionsfähigkeit des Testkreises bei der Überprüfung allgemeiner Systemeinstellungen zu gefährden. Zum Beispiel Benutzer-/Gruppe-/Passwort-/Anwendungspolitik.
- Testdaten von automatisierten Tests stören die Arbeit der manuellen Tester.
Einige werden sagen, dass gute automatisierte Tests ihre Daten aufräumen sollten. Ich habe Argumente dagegen:
- Dynamische Stände sind sehr praktisch in der Nutzung.
- Nicht jedes Objekt kann über die API aus dem System entfernt werden. Zum Beispiel ist der Aufruf zur Löschung eines Objekts nicht implementiert, da es der Geschäftslogik widerspricht.
- Bei der Erstellung eines Objekts über die API kann eine große Menge an Metadaten generiert werden, die schwer zu löschen sind.
- Wenn Tests voneinander abhängig sind, wird der Prozess der Datenbereinigung nach der Durchführung der Tests zu einem echten Kopfzerbrechen.
- Zusätzliche (und meiner Meinung nach nicht gerechtfertigte) API-Aufrufe.
- Und das Hauptargument: wenn Testdaten direkt aus der Datenbank bereinigt werden. Das wird zu einem echten PK/FK-Zirkus! Von den Entwicklern hört man: 'Ich habe doch nur eine Tabelle hinzugefügt/entfernt/umbenannt, warum sind dann 100500 Integrationstests fehlgeschlagen?'
Meiner Meinung nach ist die optimalste Lösung eine dynamische Umgebung.
- Viele nutzen docker-compose für das Starten der Testumgebung, aber nur wenige verwenden docker-compose für die Durchführung von Integrationstests in CI/CD. Außerdem ziehe ich hier Kubernetes, Swarm und andere Container-Orchestrierungsplattformen nicht in Betracht. Nicht jede Firma hat diese.
- Wenn wir sogar einen eigenen QA-Runner haben, wie können wir dann sicherstellen, dass die über docker-compose gestarteten Dienste sich nicht behindern?
- Wie sammle ich die Protokolle der getesteten Dienste?
- Wie reinige ich den Runner?
Ich habe einen eigenen GitLab-Runner für meine Projekte und bin mit diesen Fragen bei der Entwicklung konfrontiert worden. für . Genauer gesagt bei der Durchführung der Integrationstests. Hier werden wir diese Fragen anhand von Beispielen aus diesem Projekt klären.
GitLab Shell Runner
Für den Runner empfehle ich eine Linux-VM mit 4 vCPUs, 4 GB RAM und 50 GB HDD.
Im Internet gibt es viele Informationen zur Konfiguration des gitlab-runners, daher kurz:
- Wir loggen uns per SSH auf die Maschine ein.
Wenn Sie weniger als 8 GB RAM haben, empfehle ich , um zu vermeiden, dass der OOM-Killer unsere Aufgaben aufgrund von RAM-Mangel beendet. Das kann passieren, wenn mehr als 5 Aufgaben gleichzeitig ausgeführt werden. Die Aufgaben laufen langsamer, aber stabiler durch.
Beispiel mit dem OOM-Killer
Wenn Sie in den Logs der Aufgabe sehen
bash: line 82: 26474 Killed, führen Sie einfach auf dem Runner aussudo 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:0kBUnd wenn das Bild ungefähr so aussieht, dann fügen Sie Swap hinzu oder erweitern Sie den RAM.
- Installation , , , machen.
- Fügen Sie den Benutzer
gitlab-runnerzur Gruppe hinzu:dockersudo groupadd docker sudo usermod -aG docker gitlab-runner - gitlab-runner.
Öffnen Sie zur Bearbeitung
/etc/gitlab-runner/config.tomlund fügen Sie hinzu:concurrent=20 [[runners]] request_concurrency = 10Dies ermöglicht das Starten von parallelen Aufgaben auf einem einzigen Runner. Detailliertere Informationen lesen .
Wenn Sie einen leistungsstärkeren Computer haben, zum Beispiel 8 vCPU, 16 GB RAM, können Sie diese Zahlen mindestens doppelt so hoch machen. Aber alles hängt davon ab, was genau auf diesem Runner ausgeführt wird und in welcher Menge.
Das ist ausreichend.
Vorbereitung der docker-compose.yml
Die Hauptaufgabe ist eine universelle docker-compose.yml, die Entwickler / Tester sowohl lokal als auch im CI-Pipeline verwenden können.
Zunächst erstellen wir einzigartige Servicenamen für CI. Eine der einzigartigen Variablen in GitLab CI ist die Variable CI_JOB_ID. Wenn Sie angeben container_name mit dem Wert "service-${CI_JOB_ID:-local}", dann im Fall:
- wenn
CI_JOB_IDnicht in den Umgebungsvariablen definiert,
wird der Service-Nameservice-local - wenn
CI_JOB_IDin den Umgebungsvariablen definiert (zum Beispiel 123),
wird der Service-Nameservice-123
Zweitens erstellen wir ein gemeinsames Netzwerk für die gestarteten Dienste. Dies gibt uns Isolation auf Netzwerkebene, wenn mehrere Testumgebungen gestartet werden.
networks:
default:
external:
name: service-network-${CI_JOB_ID:-local}Das ist tatsächlich der erste Schritt zum Erfolg =)
Beispiel meiner docker-compose.yml mit Kommentaren
version: "3"
# Für das korrekte Funktionieren von web (php) und fmt muss
# sich der Inhalt in den Containern gemeinsam nutzen.
# In unserem Fall handelt es sich um das Verzeichnis /var/www/testrail
volumes:
static-content:
# Isolieren Sie die Umgebung auf Netzwerkebene
networks:
default:
external:
name: testrail-network-${CI_JOB_ID:-local}
services:
db:
image: mysql:5.7.22
# Jeder container_name enthält ${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}"
# Wenn die Variablen TR_HTTP_PORT oder TR_HTTPS_PORTS nicht definiert sind,
# wird der Service auf den Ports 80 bzw. 443 gestartet.
ports:
- ${TR_HTTP_PORT:-80}:80
- ${TR_HTTPS_PORT:-443}:443
volumes:
- static-content:/var/www/testrail
links:
- db
- fpm
networks:
- defaultBeispiel für einen lokalen Start
docker-compose -f docker-compose.yml up -d
Starte testrail-mysql-local ... abgeschlossen
Starte testrail-migration-local ... abgeschlossen
Starte testrail-fpm-local ... abgeschlossen
Erstelle testrail-web-local ... abgeschlossenAber nicht alles ist so einfach mit dem Start im CI.
Vorbereitung des Makefile
Ich benutze Makefile, da es sowohl für die lokale Umgebung als auch in CI sehr praktisch ist. Hier folgen Inline-Kommentare.
# У меня в проектах все вспомогательные вещи лежат в директории `.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
Überprüfen
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
Vorbereitung der .gitlab-ci.yml
Durchführung von Integrationstests
Integration:
stage: test
tags:
- my-shell-runner
before_script:
# Wir authentifizieren uns im Registry
- docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
# Generieren von pseudoeinzigartigen TR_HTTP_PORT und TR_HTTPS_PORT
- export TR_HTTP_PORT=$(shuf -i10000-60000 -n1)
- export TR_HTTPS_PORT=$(shuf -i10000-60000 -n1)
# Erstellen des Verzeichnisses mit der Job-ID
- mkdir ${CI_JOB_ID}
# Kopieren der erstellten docker-compose.yml in das Verzeichnis
# damit der Kontext für jeden Job unterschiedlich ist
- cp .indirect/docker-compose.yml ${CI_JOB_ID}/docker-compose.yml
script:
# Wir heben unser Umfeld an
- make docker-up
# Tests ausführen mit JAR (bei mir so)
- java -jar itest.jar --http-port ${TR_HTTP_PORT} --https-port ${TR_HTTPS_PORT}
# oder im Container
- docker run --network=testrail-network-${CI_JOB_ID:-local} --rm itest
after_script:
# Logs sammeln
- make docker-logs
# Umgebung stoppen
- make docker-kill
artifacts:
# Logs speichern
when: always
paths:
- logs
expire_in: 30 daysDurch die Ausführung eines solchen Jobs wird im Artefaktverzeichnis logs die Protokolle der Dienste und Tests gespeichert. Das ist sehr praktisch im Falle von Fehlern. Jeder Test schreibt parallel sein Protokoll, aber darüber werde ich separat berichten.
Bereinigung des Runners
Der Job wird nur nach einem Zeitplan gestartet.
stages:
- clean
- build
- test
Clean runner:
stage: clean
only:
- schedules
tags:
- my-shell-runner
script:
- make docker-cleanGehen wir weiter zu unserem GitLab-Projekt -> CI/CD -> Zeitpläne -> Neuer Zeitplan und fügen wir einen neuen Zeitplan hinzu
Ergebnis
Wir starten 4 Jobs in GitLab CI
In den Protokollen des letzten Jobs mit den Integrationstests sehen wir Container von verschiedenen Jobs
CONTAINER ID NAMES
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-204553539Detailliertes Protokoll
$ docker login -u gitlab-ci-token -p ${CI_JOB_TOKEN} ${CI_REGISTRY}
WARNUNG! Die Verwendung von --password über die CLI ist unsicher. Verwenden Sie --password-stdin.
WARNUNG! Ihr Passwort wird unverschlüsselt in \/home\/gitlab-runner\/.docker\/config.json gespeichert.
Konfigurieren Sie einen Credential Helper, um diese Warnung zu entfernen. Siehe
https:\/\/docs.docker.com\/engine\/reference\/commandline\/login\/#credentials-store
Anmeldung erfolgreich
$ 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
Fehler: Netzwerke gibt es nicht: testrail-network-204645172
docker network create testrail-network-${CI_JOB_ID:-local}
0a59552b4464b8ab484de6ae5054f3d5752902910bacb0a7b5eca698766d0331
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml pull
Hole web ... erledigt
Hole fpm ... erledigt
Hole migration ... erledigt
Hole db ... erledigt
docker-compose -f ${CI_JOB_ID:-.indirect}\/docker-compose.yml up --force-recreate --renew-anon-volumes -d
Erstelle Volume "204645172_static-content" mit Standardtreiber
Erstelle testrail-mysql-204645172 ...
Erstelle testrail-mysql-204645172 ... erledigt
Erstelle testrail-migration-204645172 ... erledigt
Erstelle testrail-fpm-204645172 ... erledigt
Erstelle testrail-web-204645172 ... erledigt
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c6b76f9135ed registry.gitlab.com\/touchbit\/image\/testrail\/web:latest "nginx -g 'daemon of…" Vor 13 Sekunden Lauffähig seit 1 Sekunde 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…" Vor 16 Sekunden Lauffähig seit 13 Sekunden 9000\/tcp testrail-fpm-204645172
2cdab1edbf6a registry.gitlab.com\/touchbit\/image\/testrail\/migration:latest "docker-entrypoint.s…" Vor 16 Sekunden Lauffähig seit 13 Sekunden 3306\/tcp, 33060\/tcp testrail-migration-204645172
826aaf7c0a29 mysql:5.7.22 "docker-entrypoint.s…" Vor 18 Sekunden Lauffähig seit 16 Sekunden 3306\/tcp testrail-mysql-204645172
6dbb3fae0322 registry.gitlab.com\/touchbit\/image\/testrail\/web:latest "nginx -g 'daemon of…" Vor 36 Sekunden Lauffähig seit 22 Sekunden 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…" Vor 38 Sekunden Lauffähig seit 35 Sekunden 9000\/tcp testrail-fpm-204645084
70fea72aa10d mysql:5.7.22 "docker-entrypoint.s…" Vor 40 Sekunden Lauffähig seit 37 Sekunden 3306\/tcp testrail-mysql-204645084
d8aa24b2892d registry.gitlab.com\/touchbit\/image\/testrail\/web:latest "nginx -g 'daemon of…" Vor etwa 1 Minute Lauffähig seit 53 Sekunden 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…" Vor etwa 1 Minute Lauffähig seit etwa 1 Minute 9000\/tcp testrail-fpm-204644881
685d8023a3ec mysql:5.7.22 "docker-entrypoint.s…" Vor etwa 1 Minute Lauffähig seit etwa 1 Minute 3306\/tcp testrail-mysql-204644881
1cdfc692003a registry.gitlab.com\/touchbit\/image\/testrail\/web:latest "nginx -g 'daemon of…" Vor etwa 1 Minute Lauffähig seit etwa 1 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…" Vor etwa 1 Minute Lauffähig seit etwa 1 Minute 9000\/tcp testrail-fpm-204644793
029e16b26201 mysql:5.7.22 "docker-entrypoint.s…" Vor etwa 1 Minute Lauffähig seit etwa 1 Minute 3306\/tcp testrail-mysql-204644793
c10443222ac6 registry.gitlab.com\/touchbit\/image\/testrail\/web:latest "nginx -g 'daemon of…" Vor 5 Stunden Lauffähig seit 5 Stunden 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…" Vor 5 Stunden Lauffähig seit 5 Stunden 9000\/tcp testrail-fpm-204567103
6ae0accab28d mysql:5.7.22 "docker-entrypoint.s…" Vor 5 Stunden Lauffähig seit 5 Stunden 3306\/tcp testrail-mysql-204567103
b66b60d79e43 registry.gitlab.com\/touchbit\/image\/testrail\/web:latest "nginx -g 'daemon of…" Vor 5 Stunden Lauffähig seit 5 Stunden 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…" Vor 5 Stunden Lauffähig seit 5 Stunden 9000\/tcp testrail-fpm-204553690
a8879c5ef941 mysql:5.7.22 "docker-entrypoint.s…" Vor 5 Stunden Lauffähig seit 5 Stunden 3306\/tcp testrail-mysql-204553690
069954ba6010 registry.gitlab.com\/touchbit\/image\/testrail\/web:latest "nginx -g 'daemon of…" Vor 5 Stunden Lauffähig seit 5 Stunden 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…" Vor 5 Stunden Lauffähig seit 5 Stunden 9000\/tcp testrail-fpm-204553539
1a1eed057ea0 mysql:5.7.22 "docker-entrypoint.s…" Vor 5 Stunden Lauffähig seit 5 Stunden 3306\/tcp testrail-mysql-204553539Alle Aufgaben wurden erfolgreich abgeschlossen
Die Artefakte der Aufgabe enthalten Protokolle von Diensten und Tests
Es sieht zwar alles gut aus, aber es gibt einen Haken. Der Pipeline kann während der Ausführung der Integrationstests zwangsweise abgebrochen werden, und in diesem Fall werden die gestarteten Container nicht gestoppt. Von Zeit zu Zeit muss der Runner gereinigt werden. Leider ist die Aufgabe zur Überarbeitung in GitLab CE noch im Status
Aber wir haben die Aufgabe geplant, und niemand hindert uns daran, sie manuell zu starten.
Gehen wir zu unserem Projekt -> CI/CD -> Zeitpläne und starten wir die Aufgabe Runner reinigen
Insgesamt:
- Wir haben einen Shell-Runner.
- Es gibt keine Konflikte zwischen den Aufgaben und der Umgebung.
- Wir haben einen parallelen Start der Aufgaben mit Integrationstests.
- Integrationstests können sowohl lokal als auch in Containern ausgeführt werden.
- Die Protokolle der Dienste und Tests werden gesammelt und an die Pipeline-Aufgabe angehängt.
- Es besteht die Möglichkeit, den Runner von alten Docker-Images zu reinigen.
Die Einrichtungszeit beträgt ca. 2 Stunden.
Das ist es eigentlich schon. Ich freue mich auf Ihr Feedback.
Quelle: habr.com
