Im Mai 2019 gab GitHub die Veröffentlichung des Paketregistrierungsdienstes bekannt . Im Anschluss daran wurde bereits im August die Unterstützung für CI / CD in Actions angekündigt .
In dem Artikel werde ich Ihnen erklären, welche Art von Diensten es gibt und wie diese am Beispiel eines kleinen Haustierprojekts auf GitHub verwendet werden können.
Um welche Art von Dienstleistungen handelt es sich?
GitHub Actions ist eine Plattform, mit der Sie den Software-Lebenszyklus verwalten können, dessen Quellcode auf GitHub gehostet wird. Tatsächlich haben TravisCI, CircleCI und viele andere kostenlose CI / CD-Plattformen mit Actions einen neuen Konkurrenten erhalten.
GitHub Package Registry ist das zentrale Repository für Artefakte. Derzeit werden fünf verschiedene Arten von Artefakten unterstützt.
Unterstützte Artefakttypen in Aktionen
Dies ist eine bequeme Gelegenheit, alle Artefakte an einem Ort zu haben, da es nicht immer ratsam ist, Ihren Nexus- oder Artifactory-Server bereitzustellen.
GitHub wird GitLab immer ähnlicher und irgendwo, wo es bereits einen Gegner übertroffen hat, unterstützt GitLab beispielsweise noch keine NuGet-Pakete und Ruby-Edelsteine. Wenn Sie früher für Open Source-Projekte externe Integrationen mit GitHub verbinden mussten, befinden sich jetzt alle Eier in einem Korb. Hier kann jeder entscheiden, ob es gut oder schlecht ist, aber zumindest ist es bequem.
Wie versuche ich es?
Beide Dienste befinden sich derzeit im Beta-Modus. Auf diesen Seiten können Sie sich für einen Beta-Test registrieren.
Die Migration von anderen Diensten ist sehr einfach. Ich habe mehrere meiner Lieblingsprojekte von TravisCI und DockerHub auf Actions bzw. Package Registry migriert.
Ich werde Ihnen in einem Beispiel zeigen, wie es aussieht. Das Projekt ist das häufigste, ich habe darüber in diesem Artikel geschrieben. Nichts kompliziertes, der übliche LaTeX-Code, mit dessen Hilfe Artefakte gesammelt werden (2 PDF-Dateien), werden in GitHub-Releases veröffentlicht. Um nicht eine Reihe von LaTeX-Paketen herunterzuladen, habe ich eine Docker-Datei geschrieben, damit Sie bequem von jedem Betriebssystem aus arbeiten können.
Paketregistrierung
Um mit der Paketregistrierung anstelle von DockerHub zu arbeiten, müssen Sie nur zwei einfache Schritte ausführen.
Wir erstellen ein Token in den GitHub-Einstellungen (das Token muss zum Schreiben und Lesen von Artefakten berechtigt sein).
Seite zur Token-Erstellung
Und dann können wir uns mit dem erstellten Token authentifizieren und Artefakte pushen, so einfach ist das:
docker login docker.pkg.github.com --username amet13 docker tag docker-latex:0.0.1 docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1 docker push docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1
Bitte beachten Sie, dass ich meinen Spitznamen auf GitHub ausdrücklich in Kleinbuchstaben angegeben habe, andernfalls wird von Docker eine Fehlermeldung angezeigt:
Error parsing reference: "docker.pkg.github.com/Amet13/master-thesis/docker-latex:0.0.1" is not a valid repository/tag: invalid reference format: repository name must be lowercase
So sieht es in der GitHub-Weboberfläche aus:
Paketregistrierungsseite für Docker-Images
Zusätzlich zu den Anweisungen zum Herunterladen des neuesten Bildes stehen Download-Statistiken zur Verfügung. Sie können eine separate Docker-Ebene über die Weboberfläche herunterladen. Der Download-Verlauf der Bilder ist verfügbar.
Aktionen
Aktionen sind etwas komplizierter, aber für diejenigen, die jemals mit einem anderen CI / CD-System gearbeitet haben, wird es nicht schwer zu verstehen sein. Die Konfiguration in Aktionen wird durch deklarative YAML beschrieben, obwohl zuvor HCL verwendet wurde .
Einige grundlegende Konzepte (ich werde die Definitionen nicht absichtlich übersetzen, ich denke, hier ist alles klar):
- Workflow - Ein Prozess, der den Software-Lebenszyklus (Erstellen, Testen, Packen, Freigeben, Bereitstellen) für das Repository verwaltet
- Workflow-Datei - Die Datei, in der der Workflow beschrieben wird, befindet sich im Stammverzeichnis des Repositorys im Verzeichnis
.github/workflows/ - Job ist jeder Lauf des Workflows. Job wird ausgelöst. Zu einem bestimmten Zeitpunkt können viele Jobs gestartet werden
- Schritt - Jeder Job hat einen Schritt. Bei jedem Schritt können Sie Befehle oder Aktionen ausführen
- Aktion - Ein von jemandem geschriebenes „Plug-In“. Eine Liste mit vielen Aktionen finden Sie im Repository für fantastische Aktionen
- Virtuelle Umgebung - die Umgebung, in der Job ausgeführt wird (tatsächlich handelt es sich um eine virtuelle Maschine unter Windows, MacOS oder Linux).
- Runner ist eine bereitgestellte Umgebung zum Starten eines Jobs. Es kann jeweils nur ein Job auf Runner ausgeführt werden
- Ereignis - Ein Ereignis, das den Workflow auslöst, z. B. Push, Pull Request, Webhook, Cron Job usw.
- Artefakt - Artefakte (Binärdateien, Bilder, Protokolle usw.)
So sieht die Seite Jobliste im Workflow aus.
Einschränkungen und Verbote:
- 20 Workflows pro Repository
- 1000 API-Anforderungen pro Stunde für alle Aktionen im Repository
- maximale Arbeitszeit - 6 Stunden
- 20 Jobs können im Repository parallel arbeiten (für alle Workflows)
- Es ist verboten, Aktionen für Cryptocurrency Mining und Serverless Computing zu verwenden
Die aktuellste Dokumentation finden Sie unter diesem Link .
Und hier sind die Protokolle eines Jobs
Beispiel
Kehren wir zum Beispiel zurück. Hier ist, wie meine Konfiguration aussieht. Wir werden sie in Teilen genauer analysieren.
Geben Sie einen Namen für den Workflow an und beschreiben Sie, auf welchen Trigger er ausgelöst werden soll (eine Liste aller Trigger finden Sie in der Dokumentation ):
name: master-thesis on: [push]
In welcher virtuellen Umgebung wird Job ausgeführt:
jobs: build: # ubuntu-latest, ubuntu-18.04, or ubuntu-16.04 # windows-latest, windows-2019, or windows-2016 # macOS-latest or macOS-10.14 runs-on: ubuntu-latest
Der erste Schritt, im name: Geben Sie den Namen des Schritts an (optional), und in uses: Welche Aktion möchten wir verwenden? In diesem Fall klonen Sie das Repository:
steps: - name: Checkout repo uses: actions/checkout@v1
Im nächsten Schritt verwenden wir keine Aktion, sondern nur eine Reihe unserer Befehle, mit denen wir uns bei der Paketregistrierung anmelden, das Docker-Image sammeln und in das Image-Repository verschieben. Im env: Block env: setzen Umgebungsvariablen, wir nehmen eine davon aus Geheimnissen:
- name: Build docker image and push it to the registry env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }} DOCKER_IMAGE_ORIGIN: "docker.pkg.github.com/amet13/master-thesis/docker-latex" run: | # Pull submodules git submodule init git submodule update --remote # Login to GitHub Packages and build Docker image docker login docker.pkg.github.com -u amet13 -p ${GITHUB_TOKEN} docker pull ${DOCKER_IMAGE_ORIGIN}:latest docker build -t ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} . # Generate PDF artifacts docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "latexmk -xelatex -synctex=1 -jobname=master-thesis main.tex" docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "cd presentation/ && latexmk -xelatex -synctex=1 -jobname=presentation main.tex" # Publish Docker image to GitHub Packages (with latest tag) docker tag ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} ${DOCKER_IMAGE_ORIGIN}:latest docker push ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} docker push ${DOCKER_IMAGE_ORIGIN}:latest
Ich bin sicher, dass in naher Zukunft eine Aktion angezeigt wird, die Bilder automatisch markiert und pusht, anstatt Docker-Befehle manuell zu schreiben.
Hinzufügen eines Geheimnisses mit einem Github-Token
Der nächste Schritt nach dem Erstellen der PDFs besteht darin, eine Version auf GitHub zu erstellen und die gesammelten Artefakte in diese Version aufzunehmen. Um automatisch ein Release zu erstellen, verwenden wir eine Aktion eines Drittanbieters , in der Sie im if: -Block die Bedingung für das Starten des Schritts angeben können - nur beim Erstellen des Tags:
- name: Create GitHub release with artifacts uses: softprops/action-gh-release@v1 if: startsWith(github.ref, 'refs/tags/') with: files: | master-thesis.pdf presentation/presentation.pdf name: "Build ${GITHUB_SHA}" env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
Zusammenfassung
Trotz des Beta-Status funktionieren beide Dienste gut. Ich bin sicher, dass viele Dinge erledigt sein werden.
An einigen Stellen kann es unpraktisch sein, es gibt keine globalen Variablen, aber dies kann mit Krücken erfolgen .
Ich mochte den GitHub-Ansatz, HCL zugunsten von YAML aufzugeben. Ich mochte auch die Unterstützung für viele Arten von Hosts, die (vorerst) sehr sparsam sind. Mal sehen, wie es weitergeht. Im Allgemeinen funktioniert ein solcher Haufen für einfache Pipelines in öffentlichen Repositories auf GitHub sehr gut.
Die Übersetzung dieses Artikels ist bereits auf Medium .