So veröffentlichen Sie GitHub-Versionen automatisch über Git-Tags
GitHub-Releases bieten Endbenutzern eine leicht zugängliche Methode zum Herunterladen versionierter Software-Binärdateien. Sie können sie manuell erstellen, aber es ist viel einfacher, GitHub Actions sie automatisch erstellen zu lassen, indem Sie in Ihrem Repository erstellte Release-Tags verwenden.
Verwenden getaggter Veröffentlichungen
Tags sind eine vorhandene Funktion in Git, mit erweiterter Unterstützung durch GitHub mit Releases, die einen Ort zum Hosten von Binärdateien mit zugehörigen Änderungsprotokollen bieten.
Sie können ein Tag ähnlich wie einen Zweig erstellen, mit der Ausnahme, dass es sich um einen festen Punkt handelt, der sich nicht bewegt und immer auf einen bestimmten Commit verweist. Dies ist nützlich für die Erstellung versionierter Releases, und die meisten Benutzer erstellen Tags im semantischen Versionierungsformat (Major.Minor.Patch).
Tags können an GitHub übertragen werden, wo sie in anderen Automatisierungsworkflows verwendet werden können. In diesem Fall richten wir ein GitHub-Aktionsskript ein, das auf Commits mit getaggten Releases wartet und die Build-Artefakte automatisch in einem Release veröffentlicht.
Einrichten von GitHub-Aktionen
Zunächst möchten Sie sicherstellen, dass Sie über einen funktionierenden GitHub Actions-Build verfügen und dass Ihre Build-Skripte ordnungsgemäß funktionieren. Die genaue Einrichtung Ihres Workflows hängt von der Art des Projekts ab, das Sie erstellen. Im Allgemeinen möchten Sie jedoch nicht zwei Probleme gleichzeitig debuggen. Daher sollten Sie die Release-Veröffentlichung hinzufügen, sobald Sie bereits über funktionierende Artefakte verfügen. Sie können unseren Leitfaden zum Einrichten eines GitHub Actions-Builds lesen, um mehr zu erfahren.
Als Erstes müssen Sie den Abschnitt „Ein“ Ihres Aktionsskripts so bearbeiten, dass er auch ausgeführt wird, wenn Tags erstellt werden. Standardmäßig verfügen Sie wahrscheinlich über das „Push“-Ereignis, um Releases oder den Master-Zweig zu verfolgen. Sie müssen Tags hinzufügen und einen Filter festlegen. Für alle Tags verwenden Sie einfach einen Platzhalter:
Am Ende des Workflows, nachdem alles erstellt wurde, erstellen wir den Release-Eintrag. Dies ist ein zweiteiliger Schritt: Zuerst müssen wir ein neues Release-Objekt mit allen Metadaten erstellen und dann können wir die ausgegebene Veröffentlichungs-URL dafür verwenden, um die Artefakte hochzuladen. Sie können mehrere Upload-Schritte erstellen, wenn Sie über mehrere Artefakte verfügen.
In beiden Fällen möchten wir diese Schritte nur ausführen, wenn der Workflow aufgrund eines Tags ausgeführt wird. Wir können dies mit einer einfachen ifPrüfung tun und prüfen, ob das github.refObjekt ein Tag ist, das den Referenznamen des Zweigs oder Tags speichert, der den Workflow ausgelöst hat.
Der erste Schritt besteht darin, ein Release-Objekt zu erstellen, was mit dem folgenden Schritt erfolgen kann. Das GitHub-Token muss nicht manuell erstellt werden – es ist ein spezielles Token, auf das jederzeit von Aktionsskripten aus verwiesen werden kann.
- name: Create Release
if: startsWith(github.ref, 'refs/tags/')
uses: actions/create-release@v1
id: create_release
with:
draft: false
prerelease: false
release_name: ${{ github.ref }}
tag_name: ${{ github.ref }}
body_path: CHANGELOG.md
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Beachten Sie hier, dass das Änderungsprotokoll für die Version unter gespeichert ist CHANGELOG.md, das vorhanden sein muss, damit der Workflow ordnungsgemäß ausgeführt werden kann . Sie können dies mit jedem Tag bearbeiten, um den von GitHub auf der Release-Seite angezeigten Markdown zu ändern. Es gibt Tools, um dies automatisch mit Commit-Nachrichten zu generieren, aber die meisten Teams verfügen ohnehin über ihre eigene Methode, dies zu verwalten.
Als Nächstes können Sie mit dem Hochladen von Artefakten beginnen. Dabei wird die Upload-URL aus dem vorherigen Schritt verwendet, und Sie müssen einen Pfad definieren, unter dem sie zusammen mit dem Anzeigenamen für das Asset gefunden werden kann.
- name: Upload Release
if: startsWith(github.ref, 'refs/tags/')
uses: actions/upload-release-asset@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ steps.create_release.outputs.upload_url }}
asset_path: Oxide.Ext.Sanctuary/bin/Release/net48/Oxide.Ext.Sanctuary.dll
asset_name: Oxide.Ext.Sanctuary.dll
asset_content_type: application/octet-stream
Beachten Sie hier, dass der Inhaltstyp auf festgelegt ist octet-stream, was typisch für Binärdaten wie ausführbare Dateien und DLLs ist. Wenn Sie eine ZIP-Datei oder eine andere Art von Datei veröffentlichen, möchten Sie dies möglicherweise ändern, obwohl dies nur die visuellen Elemente auf der Veröffentlichungsseite betrifft.
Jetzt können Sie die Änderungen in den Aktionsworkflow übernehmen, dann ein neues Tag erstellen und es an GitHub übertragen. Sie sollten sehen, dass eine neue Workflow-Ausführung erstellt wird, mit dem Unterschied, dass sie nicht über den Master-Zweig ausgeführt wird, sondern aufgrund des Tags:
Sobald es fertig ist, sehen Sie die Veröffentlichung in der GitHub-Seitenleiste.
Schreibe einen Kommentar