Auspacken der Möglichkeiten von GitHub-Paketen

Vor einiger Zeit habe ich ein Github-Projekt geforkt und es auf Bintray veröffentlicht, damit es von einem meiner anderen Projekte als Abhängigkeit verwendet werden kann. Da die Veröffentlichung auf Bintray ziemlich mühsam war, beschloss ich, einen Blick auf GitHub Packages zu werfen, das letztes Jahr veröffentlicht wurde. Meine Frage war, ob dies eine einfachere Möglichkeit wäre, ein Paket zu veröffentlichen und es in einem anderen Projekt als Abhängigkeit zu verwenden. Lassen Sie es uns herausfinden.

Veröffentlichen auf GitHub Pakete

Es gibt mehrere Sprachen und Frameworks, die von GitHub Packages unterstützt werden. Mein Projekt verwendet Java als Programmiersprache und Gradle als Build-Tool. Als erstes musste ich die Datei "build.gradle" ändern.

Wie Sie sehen können, sind Anmeldeinformationen erforderlich, um ein Paket auf GitHub zu veröffentlichen. Diese Zugangsdaten können in einer separaten Datei mit dem Namen "gradle.properties" gespeichert werden (die zu ".gitignore" hinzugefügt wird, um sie privat zu halten), die den folgenden Text enthält:

gpr.user=[GITHUB_USERNAME]
gpr.key=[GITHUB_TOKEN]

Ein GitHub-Token erhalten

Um dieses GitHub-Token zu erhalten, gehen Sie einfach auf Ihre GitHub-Einstellungsseite und generieren Sie eines gemäß der GitHub-Dokumentation. Es muss den richtigen Geltungsbereich haben, um Pakete zu veröffentlichen.

Jetzt müssen Sie nur noch ein Terminal im Verzeichnis des Projekts öffnen und es ausführen (vorausgesetzt, Sie verwenden den Gradle-Wrapper):

./gradlew publish

Das war's. Das Paket wird auf Github veröffentlicht. Überhaupt nicht zu kompliziert.

Hinzufügen eines GitHub-Pakets als Abhängigkeit

Natürlich ist das nur die halbe Miete. Die Veröffentlichung eines Pakets ist eine Sache, die Abhängigkeit von einem anderen Softwareprojekt eine andere. Aber hey, dachte ich, das kann doch nicht so kompliziert sein. Die Abhängigkeit kann gleich bleiben, da sich die groupId und artifactId nicht geändert haben. Ich muss nur die Version in der "pom.xml" ändern, da ich Maven als Build-Tool in dem Projekt verwendet habe, das von dem ersten abhing.

<dependency>
    <groupId>benjaminkomen</groupId>
    <artifactId>jwiki</artifactId>
    <version>${jwiki.version}</version>
</dependency>

Oh, und ich füge meinen GitHub-Paketstandort als Repository hinzu, damit Maven weiß, von welcher URL es die Abhängigkeit herunterladen muss.

<repositories>
    <repository>
        <id>github</id>
        <url>https://maven.pkg.github.com/benjaminkomen/jwiki</url>
    </repository>
</repositories>

Ich habe meine Änderungen übertragen und veröffentlicht, aber dann ist mein Travis CI-Build fehlgeschlagen: Failed to collect dependencies at benjaminkomen:jwiki:jar:2.2.0: Failed to read artifact descriptor for benjaminkomen:jwiki:jar:2.2.0: Could not transfer artifact benjaminkomen:jwiki:pom:2.2.0 from/to github (https://maven.pkg.github.com/benjaminkomen/jwiki): Authentication failed for https://maven.pkg.github.com/benjaminkomen/jwiki/benjaminkomen/jwiki/2.2.0/jwiki-2.2.0.pom 401 Unauthorized -> [Help 1]

Nicht autorisiert? Ich habe mit Schrecken festgestellt, dass Sie tatsächlich ein GitHub-Token mit dem Geltungsbereich read:packages benötigen, um während des (Maven-)Build-Prozesses eine Abhängigkeit von GitHub-Paketen abzurufen. Das ist in der Tat ziemlich lästig. Aber geben wir nicht auf, sondern versuchen wir, das Problem zu lösen.

Authentifizierung bei GitHub-Paketen

Natürlich wird das alles in der Dokumentation erklärt (aber wer liest das schon im Voraus?). Führen Sie in Ihrem Terminal einfach aus:

subl ~/.m2/settings.xml

Hinweis: 'subl' steht für 'Sublime Text', Sie können alternativ auch 'vim' oder einen anderen Texteditor verwenden.

Kopieren Sie dann den XML-Code der Einstellungen aus der Dokumentation in Ihre lokale Datei "setting.xml" und ersetzen Sie einige Platzhalter. Es ist ratsam, das zuvor erstellte GitHub-Token für die Veröffentlichung auf GitHub Packages nicht wieder zu verwenden. Nach dem Prinzip der geringsten Rechte ist es besser, ein neues GitHub-Token zu erstellen, das nur die Möglichkeit hat, Pakete zu lesen und sie nicht zu veröffentlichen.

Das Speichern dieser Datei "settings.xml" sorgt dafür, dass Ihr lokaler Build funktioniert, aber damit der Travis CI-Build erfolgreich ist, musste mehr Arbeit geleistet werden. Die Lösung, die ich fand, war in der Theorie einfach: Kopieren Sie während eines Builds die Datei "settings.xml" an den richtigen Ort auf dem Build-Server. Auf diese Weise kann das GitHub-Paket während des Builds abgerufen werden. Das zu erstellende Repository ist jedoch öffentlich, so dass die Datei "settings.xml" das GitHub-Token nicht enthalten sollte. Auch wenn es nur Lesezugriff bietet, fühlt es sich seltsam an, ein persönliches Token öffentlich verfügbar zu haben. Glücklicherweise erlaubt Travis das Hinzufügen von Umgebungsvariablen über seine Einstellungsseite.

Also fügte ich dem Projekt eine Datei namens ".travis.settings.xml" hinzu, die nicht das GitHub-Token enthielt, sondern einfach einen Verweis auf die Umgebungsvariable ${env.GITHUB_TOKEN} ). Außerdem musste die Datei ".travis.yml" geändert werden, um die Datei ".travis.settings.xml" während des Builds an den richtigen Ort zu kopieren.

Interessanterweise muss dies während des Installationsschritts geschehen, nicht während des Skriptschritts.

Und voila, es funktioniert! Während eines Travis-Builds wird eine "settings.xml" auf den Build-Server kopiert und eine Umgebungsvariable wird verwendet, um das erforderliche GitHub-Token zu speichern.

Die Saga geht weiter - Google Cloud

Natürlich war Travis nur einer der Orte, an denen dieses Projekt gebaut wurde. Beim Zusammenführen mit dem Master-Zweig bewirkt ein Auslöser, dass das Projekt in der Google Cloud von Cloud Build gebaut wird. Dadurch wird ein Docker-Image erstellt, das in Cloud Ausführen. Ein weiterer Ort, der eine Autorisierung benötigte, um mein stolz veröffentlichtes GitHub-Paket herunterzuladen.

Ich entschied mich für eine Lösung, bei der ich die "settings.xml"-Datei, die ich für Travis verwendet habe, wiederverwenden und das GitHub-Token in Cloud KMS, der Google Cloud-Methode zur Speicherung von Geheimnissen, speichern konnte (Hinweis: seit Januar 2020 kann alternativ auch der Secret Manager verwendet werden).

Verwendung des Cloud Key Management Service

Als erstes sollte die Cloud KMS API aktiviert werden. Dann müssen ein Schlüsselbund und ein Schlüssel erstellt werden. Ich habe ganz einfach die Cloud Shell aus dem Google Cloud Dashboard verwendet. Um einen Schlüsselring mit dem Namen "my-secrets" zu erstellen, führen Sie im Terminal der Cloud Shell aus:

gcloud kms keyrings create my-secrets --location global

Um dann einen Schlüssel mit dem Namen "github-token" in diesem Schlüsselbund zu erstellen und ihn anzuzeigen, führen Sie aus:

gcloud kms keys create github-token --location global --keyring my-secrets --purpose encryption
gcloud kms keys list --location global --keyring my-secrets

Nun kann der tatsächliche Wert des GitHub-Tokens hinzugefügt werden, oder genauer gesagt, der verschlüsselte Wert. Zunächst müssen Sie den GitHub-Token in eine Klartextdatei einfügen, indem Sie ihn einfach ausführen:

echo "[GITHUB TOKEN]" > github_token.txt

Dann kann die eigentliche Verschlüsselung durchgeführt werden:

gcloud kms encrypt 
  --plaintext-file=github_token.txt 
  --ciphertext-file=github_token.enc.txt 
  --location=global 
  --keyring=my-secrets 
  --key=github-token

Für den Cloud Build benötigen Sie eine base64-kodierte Version des verschlüsselten Tokens, die Sie dann im Terminal ausdrucken, kopieren und verwenden können:

base64 github_token.enc.txt -w 0 > github_token.enc.64.txt
cat github_token.enc.64.txt

Sie können die Ausgabe des vorherigen Befehls zur späteren Verwendung kopieren und einfügen. Anschließend ist es ratsam, die drei erstellten Textdateien zu löschen, da sie noch eine Weile bestehen bleiben werden.

Cloud Build konfigurieren

Gut, dann ist alles getan, um unseren GitHub-Token sicher zu speichern, damit er während des Cloud Builds verwendet werden kann. Der Cloud Build-Prozess benötigt möglicherweise die Erlaubnis, während des Builds auf Ihren CryptoKey zuzugreifen, aber das lässt sich leicht bewerkstelligen. Darüber hinaus waren in der Datei "cloudbuild.yaml" einige Änderungen erforderlich.

Der untere Teil nach secrets enthält den Teil, in dem das GitHub-Token, das als verschlüsselter Schlüssel in Cloud KMS gespeichert ist, gelesen wird, damit es als Umgebungsvariable verwendet werden kann. Hier wird die base64-kodierte Version des verschlüsselten GitHub-Tokens verwendet, wie in der Dokumentation beschrieben.

Darüber hinaus kann das GitHub-Token nun als geheime Umgebungsvariable betrachtet werden, die als Build-Argument an das "Dockerfile" übergeben werden kann. Die Build-Phase dieses Docker-Images ist der Ort, an dem Maven die Abhängigkeiten einzieht und Zugriff auf die GitHub-Pakete haben muss. Das "Dockerfile" ändert sich also auf folgende Weise:

Es erhält die GITHUB_TOKEN als Argument aus der Cloud Build-Datei. Anschließend veröffentlicht es diese als Umgebungsvariable. Schließlich kopiert es die Datei "settings.xml" an den richtigen Ort, der nun die GitHub-Token-Umgebungsvariable verwenden kann, um das GitHub-Paket zu holen, das wir zuvor veröffentlicht haben.

Das war's. Cloud Build ist jetzt auch so eingerichtet, dass es während der Erstellung GitHub-Pakete abruft!

Fazit

Was haben wir herausgefunden? Das Veröffentlichen von Paketen auf GitHub ist relativ einfach. Es genügt, ein GitHub-Token zu erstellen und einige Konfigurationsänderungen vorzunehmen.

Leider ist es schwieriger, ein GitHub-Paket als Abhängigkeit zu verwenden. Im Gegensatz zu anderen Abhängigkeiten (z.B. von der Maven-Zentrale) ist für den Download eines GitHub-Pakets während der Erstellung eines Programms eine Authentifizierung erforderlich. Damit dies funktioniert, ist eine gewisse Konfiguration erforderlich. Diese muss in jeder Build-Umgebung vorgenommen werden, in der diese Abhängigkeit verwendet wird.

Die Tatsache, dass es dadurch so viel schwieriger wird, macht die Nutzung von GitHub-Paketen weniger attraktiv.

Aber hey, wer weiß, vielleicht verwende ich GitHub-Pakete ja völlig falsch? Vielleicht ist es vor allem für GitHub-Aktionen gedacht, bei denen Sie sich keine Gedanken über ein GitHub-Token machen müssen? Ich würde gerne Ihre Meinung hören!