Freigeben und Verwalten von Aktionen

Du kannst Automatisierung und bewährte Open-Source-Methoden nutzen, um Aktionen zu veröffentlichen und zu verwalten.

In diesem Artikel

Einführung

Nachdem du eine Aktion erstellt hast, möchtest du weiterhin neue Features veröffentlichen, während du mit Communitybeiträgen arbeitest. In diesem Tutorial wird ein Beispielprozess beschrieben, den du zum Freigeben und Verwalten von Aktionen in Open Source befolgen kannst. Beispiel:

  • Nutzen von GitHub Actions für Continuous Integration, Abhängigkeitsupdates, Releaseverwaltung und Aufgabenautomatisierung
  • Schaffen von Vertrauen durch automatisierte Tests und Buildbadges
  • Angeben der Einsatzmöglichkeiten der Aktion, idealerweise als Teil eines breiteren Workflows
  • Signalisieren der gewünschten Art von Communitybeiträgen (Beispiele: Issues, Pull Requests oder Sicherheitsrisikoberichte)

Ein Anwendungsbeispiel für diesen Prozess findest du unter actions/javascript-action.

Entwickeln und Freigeben von Aktionen

In diesem Abschnitt diskutieren wir einen Beispielprozess zum Entwickeln und Freigeben von Aktionen und zeigen, wie GitHub Actions zum Automatisieren des Prozesses verwendet wird.

Informationen zu JavaScript-Aktionen

JavaScript-Aktionen sind Node.js-Repositorys mit Metadaten. Im Vergleich zu herkömmlichen Node.js-Projekten weisen JavaScript-Aktionen jedoch zusätzliche Eigenschaften auf:

  • Abhängige Pakete werden zusammen mit dem Code committet, in der Regel in einem kompilierten und minimierten Format. Dies bedeutet, dass automatisierte Builds und sichere Communitybeiträge wichtig sind.

  • Versionen mit Tags können direkt im GitHub Marketplace veröffentlicht und von Workflows in GitHub verwendet werden.

  • Viele Aktionen nutzen GitHub-APIs und APIs von Drittanbietern, daher empfehlen wir gründliche End-to-End-Tests.

Einrichten von GitHub Actions-Workflows

Um den Entwicklerprozess im nächsten Abschnitt zu unterstützen, füge deinem Repository zwei GitHub Actions-Workflows hinzu:

  1. Füge einen Workflow hinzu, der ausgelöst wird, wenn ein Commit an einen Featurebranch oder an main gepusht oder wenn ein Pull Request erstellt wird. Konfiguriere den Workflow, um deine Komponenten- und Integrationstests auszuführen. Sieh dir beispielsweise diesen Workflow an.
  2. Füge einen Workflow hinzu, der ausgelöst wird, wenn ein Release veröffentlicht oder bearbeitet wird. Konfiguriere den Workflow, um sicherzustellen, dass semantische Tags vorhanden sind. Du kannst eine Aktion wie JasonEtco/build-and-tag-action verwenden, um die JavaScript- und Metadatendatei zu kompilieren und als Paket zu erstellen und die Pushübertragung semantischer Haupt-, Neben- und Patchtags zu erzwingen. Weitere Informationen zu semantischen Tags findest du unter Informationen zur semantischen Versionierung.

Beispielentwicklerprozess

Nachfolgend findest du einen Beispielprozess, mit dem du Tests automatisch ausführen, ein Release erstellen, in GitHub Marketplace veröffentlichen und deine Aktion veröffentlichen kannst.

  1. Führe Featurearbeit in Branches über einen GitHub-Flow aus. Weitere Informationen finden Sie unter GitHub-Flow.

    • Wenn ein Commit an den Featurebranch gepusht wird, führt dein Testworkflow die Tests automatisch aus.

  2. Erstelle Pull Requests an den main-Branch, um Diskussionen und Reviews zu initiieren. Bei Bereitschaft wird ein Mergevorgang durchgeführt.

    • Wenn ein Pull Request aus einem Branch oder einem Fork geöffnet wird, führt der Testworkflow die Tests erneut aus, dieses Mal mit dem Mergecommit.

    • Hinweis: Aus Sicherheitsgründen verfügen Workflows, die über pull_request aus Forks ausgelöst werden, über eingeschränkte GITHUB_TOKEN-Berechtigungen und können nicht auf Geheimnisse zugreifen. Wenn deine Tests oder andere Workflows, die nach einem Pull Request ausgelöst werden, Zugriff auf Geheimnisse erfordern, solltest du ein anderes Ereignis wie beispielsweise einen manuellen Trigger oder ein pull_request_target verwenden. Weitere Informationen finden Sie unter Ereignisse zum Auslösen von Workflows.

  3. Erstelle eine Version mit semantischen Tags. Du kannst auch mit einem einfachen Kontrollkästchen auf dem GitHub Marketplace veröffentlichen. Weitere Informationen findest du unter Veröffentlichungen in einem Repository verwalten und unter Aktionen auf dem GitHub-Marktplatz veröffentlichen.

    • Wenn ein Release veröffentlicht oder bearbeitet wird, übernimmt dein Releaseworkflow automatisch die Kompilierung und Anpassung von Tags.

    • Es wird empfohlen, Releases mithilfe von semantischen Versionstags (z. B. v1.1.3) zu erstellen und Tags von Hauptversionen (v1) und Nebenversionen (v1.1) mit dem neuesten entsprechenden Commit auf dem neuesten Stand zu halten. Weitere Informationen findest du unter Informationen zu benutzerdefinierten Aktionen und Informationen zur semantischen Versionierung.

Ergebnisse

Im Gegensatz zu einigen anderen Strategien zur automatisierten Releaseverwaltung committet dieser Prozess absichtlich keine Abhängigkeiten an den main-Branch, sondern nur an die mit Tags versehenen Releasecommits. Dadurch werden Benutzer deiner Aktion dazu veranlasst, auf benannte Tags oder shas zu verweisen, und du stellst die Sicherheit der Pull Requests von Drittanbietern sicher, indem du den Build während eines Release selbst erstellst.

Mit semantischen Releases können die Benutzer deiner Aktionen ihre Workflows an eine Version anheften und wissen, dass sie je nach Komfortniveau weiterhin die neuesten stabilen Features ohne Breaking Changes erhalten.

Arbeiten mit der Community

GitHub bietet Tools und Anleitungen, die dich bei der Arbeit mit der Open-Source-Community unterstützen. Die folgenden Tools werden für eine solide bidirektionale Kommunikation empfohlen. Indem du der Community die folgenden Signale bereitstellst, ermutigst du andere, deine Aktion zu verwenden, zu ändern und dazu beizutragen:

Weiterführende Themen

Beispiele für die Verwendung ähnlicher Muster: