Skip to main content

Enterprise Server 3.20 ist derzeit als Release Candidate verfügbar.

Freigeben und Verwalten von Aktionen

Sie können automatisierungs- und open source bewährte Methoden nutzen, um Aktionen freizugeben und zu verwalten.

Github-gehostete Runner für Unternehmen

Einführung

Nachdem du eine Aktion erstellt hast, möchtest du weiterhin neue Funktionen veröffentlichen, während du mit Community-Beiträgen arbeitest. In diesem Lernprogramm wird ein Beispielprozess beschrieben, den Sie zum Freigeben und Verwalten von Aktionen in open source befolgen können. Beispiel:

  • Nutzt GitHub Actions für kontinuierliche Integration, Abhängigkeitsupdates, Releaseverwaltung und Aufgabenautomatisierung.
  • Durch automatisierte Tests und Build-Badges wird Vertrauen geschaffen.
  • Angeben der Einsatzmöglichkeiten der Aktion, idealerweise als Teil eines breiteren Workflows
  • Signalisieren Sie, welche Arten von Community-Beiträgen Sie willkommen heißen. (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.

  • 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 Feature-Branch oder an main gepusht wird, 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 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 geöffnet wird, entweder von einem Branch oder einem Fork, führt Ihr Testworkflow die Tests erneut aus, diesmal mit dem Merge-Commit.

    •      **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](/actions/using-workflows/events-that-trigger-workflows#manual-events) oder ein [`pull_request_target`](/actions/using-workflows/events-that-trigger-workflows#pull_request_target) verwenden. Weitere Informationen finden Sie unter [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#pull-request-events-for-forked-repositories).
      
  3. Erstelle ein semantisch getaggtes Release. Weitere Informationen findest du unter Veröffentlichungen in einem Repository verwalten.

    • 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 Verwalten benutzerdefinierter Aktionen und Informationen zur semantischen Versionierung.

Ergebnisse

Im Gegensatz zu einigen anderen automatisierten Strategien zur Release-Verwaltung überträgt dieser Prozess absichtlich keine Abhängigkeiten in den main-Branch, sondern nur in die mit Tags versehenen Release-Commits. 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 stellt Tools und Leitfäden bereit, die Ihnen bei der Arbeit mit der open source Community helfen. Im Folgenden sind einige Tools aufgeführt, die wir für eine gesunde bidirektionale Kommunikation empfehlen zu installieren. Indem du der Community die folgenden Signale bereitstellst, ermutigst du andere, deine Aktion zu verwenden, zu ändern und dazu beizutragen:

Weitere Informationen

Beispiele für die Verwendung ähnlicher Muster:

  •         [github/super-linter](https://github.com/github/super-linter)
    
  •         [octokit/request-action](https://github.com/octokit/request-action)
    
  •         [actions/javascript-action](https://github.com/actions/javascript-action)