Hallo zusammen 
Ein kleines Tutorial für Gladys-Entwickler, das erklärt, wie man ein Docker-Testimage erstellt.
Voraussetzungen:
Ein Docker Hub-Konto haben
Schritt 1: Erstellen Sie diese Umgebungsvariablen in GitHub Actions
Gehen Sie zu Ihrem Fork von Gladys, in die « Einstellungen » Ihres Repos:
Erstellen Sie diese Geheimnisse:
DOCKERHUB_PASSWORD (Kann ein API-Schlüssel-Passwort sein)
DOCKERHUB_REPO (Das Docker-Image zum Pushen, z. B. `pierregilles/gladys-test`)
DOCKERHUB_USER (Dein Benutzername auf DockerHub)
**Schritt 2: Gehen Sie zum Tab « Actions » => « Build Gladys dev images »
Ich habe es versucht und bin auf einige Punkte gestoßen, also präzisiere ich hier, was ich schließlich verstanden habe. Vielleicht hilft es anderen 
Ich hatte aus dieser Seite verstanden, dass ich ein Github-Konto und ein Repository benötige, um den Code von Gladys zu klonen. Aber ich hatte nicht sofort verstanden, dass ich auch ein Docker-Konto mit einem Repository benötige. Das Konto wird hier erstellt und das Repository auf der Seite https://hub.docker.com/repository/create?namespace=[Ihr Docker-Benutzername]. Und dieser Repository-Name muss in Github als Geheimnis DOCKERHUB_REPO konfiguriert werden (im Format [Docker-Kontoname/Repositoryname]).
Das Geheimnis DOCKER_USER ist der Name des Docker-Kontos, einfach. Aber das Geheimnis DOCKER_PASSWORD ist nicht das Passwort dieses Docker-Kontos. Man muss ein ‹ Personal Access Token › in Docker erstellen (auf der Seite https://app.docker.com/accounts/[Name Ihres Docker-Kontos]/settings/personal-access-tokens), mit den Zugriffsrechten ‹ Read, Write, Delete ›.
Wenn man dann auf die Github-Actions-Seite geht, ist ‹ Build Gladys dev images › nicht direkt sichtbar. Man muss zuerst die Warnung bestätigen, die sagt ‹ I understand my workflows ›.
Wenn man den Schritt ‹ Run workflow › startet, erscheint eine Meldung « Workflow run was successfully requested. », was bedeutet, dass der Build im Hintergrund auf den Servern von docker.com läuft (und nicht lokal auf meinem PC). Wenn man zur ‹ Actions ›-Seite zurückkehrt, hat man die Bestätigung, dass der Build läuft…
Letzter Punkt: Ich musste den Build dreimal neu starten. Beim ersten und zweiten Mal gab es einen Fehler mit der Meldung « unable to access ‹ xxx (Michael Dungan) · GitHub ›: The requested URL returned error: 500 ». Offensichtlich sind dies ‹ klassische › Probleme, wenn Docker und/oder Github etwas überlastet sind…
Ein weiterer Punkt, den ich nicht verstanden hatte: Das auf docker.com erstellte Repository muss (auf der Seite ‹ Einstellungen ›) als öffentliches Repository konfiguriert werden, selbst wenn es nicht für andere Benutzer bestimmt ist. Denn sonst findet der Befehl ‹ docker run… › zum Bereitstellen dieser Version auf Ihrer Hardware das Repository nicht, und die folgende Fehlermeldung wird angezeigt:
Unable to find image ‹ xxx/xxx:xxx › locally
docker: Error response from daemon: pull access denied for xxx/xxx, repository does not exist …
@StephaneB oder du kannst auf deiner Maschine ein docker login durchführen, wenn du dein Repository privat halten möchtest!
