Nutze die Nacht
Sprichwort

"Wenn man viele verschiedene Farben in einem Topf rührt, kommt meistens braun dabei heraus." - Thomas Eimers

SD2IEC - virtuelles Diskettenlaufwerk für den C16

Das Laden von Programmen per Datasette klappt zwar noch, ist aber langsam und langfristig riskant. Deshalb habe ich jetzt meinen Commodore 16 mit einem internen SD2IEC ausgestattet: minimaler Aufwand, rückbaubar und zuverlässig. Hier zeige ich kurz, wie es funktioniert, und wie man bequem auf der SD-Karte gespeicherte Programme per Filebrowser laden kann.

Automatisierter MySQL-Dump-Import in GitLab CI ohne Volume-Mounts

Beim automatischen Setup von Testdatenbanken im Rahmen eines GitLab-CI Pipeline Jobs müssen meist mehre SQL-Dumps importiert werden. Dazu wird üblicherweise mysql als Service gestartet und dann die Datenbank via CLI importiert. Aber eigentlich importieren die mariadb Docker container automtaisch dateien im verzeichnis /docker-entrypoint-initdb.d/ . Aber da es in CI keine direkten Volume-Mounts gibt benötigt man einen Workaround.

Show all projects!

Automatisierter MySQL-Dump-Import in GitLab CI ohne Volume-Mounts

Beim automatischen Setup von Testdatenbanken im Rahmen eines GitLab-CI Pipeline Jobs müssen meist mehre SQL-Dumps importiert werden. Dazu wird üblicherweise mysql/mariadb als Service gestartet und dann die Datenbank via CLI importiert. Aber eigentlich importieren die mariadb Docker container automtaisch dateien im verzeichnis /docker-entrypoint-initdb.d/ . Aber da es in CI keine direkten Volume-Mounts gibt benötigt man einen Workaround.

Hintergrund / Herausforderung

  • GitLab erlaubt bei CI-Jobs keine expliziten Volume Mounts im Service-Container.
  • Der übliche Weg, SQL-Dateien automatisch zu importieren (Dateien ins Verzeichnis /docker-entrypoint-initdb.d legen), ist auf diese Weise nicht direkt realisierbar.
  • Übliche Lösung: Verwendung eines manuellen MySQL-CLI-Imports im Stile von `mysql -u root -h codeception-database mms_dev < tests/initPipelineDB/mms_dev_structure.sql` in den Skripten, der allerdings aufwändiger und fehleranfälliger sein kann.

Eleganter Lösungsansatz

Alle Repository-Dateien des GitLab-Projekts sind bereits standardmäßig im MySQL-Service-Container im Verzeichnis /builds/[GROUP]/[REPO_NAME]/ verfügbar. Diese Tatsache lässt sich nutzen, indem beim Container-Start ein kleiner individueller Entrypoint-Befehl integriert wird.

Codeception:
 stage: analyze
 interruptible: true
 image: php-mit-pcov
 dependencies: [ "Install Composer dependencies" ]
 needs: [ "Install Composer dependencies" ]
 services:
 - name: mariadb
 alias: codeception-database
 entrypoint: [ "/bin/sh", "-c", "cp -R /builds/[GROUP]/[REPO_NAME]/tests/initPipelineDB/* /docker-entrypoint-initdb.d/ && exec docker-entrypoint.sh --sql-mode=" ]
 - name: redis:6.2
 alias: redis
 script:
 - vendor/bin/codecept build
 - vendor/bin/codecept run

Erklärung des angepassten Entrypoints

  1. Kopieren der SQL-Dumps: Alle relevanten SQL-Dateien aus dem Repositoryverzeichnis /builds/[GROUP]/[REPO_NAME]/tests/initPipelineDB/ werden nach /docker-entrypoint-initdb.d/ kopiert.
  2. Ausführen des Standard-Docker-Entrypoints: Durch Abschließen mit exec docker-entrypoint.sh --sql-mode= wird danach die normale MySQL-Startprozedur durchgeführt. MySQL erkennt automatisch Dateien in /docker-entrypoint-initdb.d/ und importiert sie.

Vorteile dieser Lösung

  • Kein Aufwand bei manueller Verwaltung von Imports über Befehle und CLI-Skripte.
  • Reduzierung der Job-Logik auf wenige, einfache Zeilen im CI-Job.

Article relase date: / Last update: