Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.
- For more information about upgrading to GitHub Enterprise Server 3.0 or later, see "Upgrading GitHub Enterprise Server."
- For more information about configuring GitHub Actions after you upgrade, see the documentation for GitHub Enterprise Server 3.0.
Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.
Einführung
CircleCI und GitHub Actions ermöglichen es Dir, Workflows zu erstellen, die Code automatisch bauen, testen, veröffentlichen, freigeben und bereitstellen. CircleCI und GitHub Actions haben einige Ähnlichkeiten in der Workflow-Konfiguration:
- Workflow-Konfigurationsdateien werden in YAML geschrieben und im Repository gespeichert.
- Workflows umfassen einen oder mehrere Jobs.
- Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
- Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.
Weitere Informationen findest Du unter „Kernkonzepte für GitHub Actions“.
Wesentliche Unterschiede
Betrachte bei der Migration von CircleCI folgende Unterschiede:
- Die automatische Testparallelität des CircleCI gruppiert die Tests automatisch nach benutzerdefinierten Regeln oder historischen Zeitinformationen. Diese Funktionalität ist in GitHub Actions nicht eingebaut.
- Aktionen, die in Docker-Containern ausgeführt werden, sind sensibel für Berechtigungsprobleme, da Container eine andere Zuordnung von Benutzern haben. Du kannst viele dieser Probleme vermeiden, indem Du die Anweisung
USER
in Deinem Dockerfile nicht verwendest. For more information about the Docker filesystem on GitHub Enterprise Server-hosted runners, see "Virtual environments for GitHub Enterprise Server-hosted runners."
Workflows und Jobs migrieren
CircleCI definiert Workflows
in der Datei config.yml, wodurch Du mehrere Workflows konfigurieren kannst. GitHub Enterprise Server benötigt pro Workflow eine Workflow-Datei und erfordert daher nicht Workflows
zu deklarieren. Du musst für jeden Workflow, der in config.yml konfiguriert ist, eine neue Workflow-Datei erstellen.
Sowohl CircleCI als auch GitHub Actions konfigurieren Jobs
in der Konfigurationsdatei, und das mit ähnlicher Syntax. Wenn Du Abhängigkeiten zwischen Jobs in Deinem CircleCI-Workflow mit requires
konfigurierst, kannst Du in GitHub Actions die äquivalente Syntax needs
verwenden. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.
„Orbs“ (Gestirne) zu Aktionen migrieren
Sowohl CircleCI als auch GitHub Actions bieten einen Mechanismus, um Aufgaben in einem Workflow wiederzuverwenden und weiterzugeben. CircleCI verwendet ein Konzept namens „Orbs“ (Gestirne), das in YAML geschrieben ist, um Aufgaben bereitzustellen, die man in einem Workflow wiederverwenden kann. GitHub Actions hat mächtige und flexible wiederverwendbare Komponenten namens Aktionen, die man entweder mit JavaScript-Dateien oder mit Docker-Images erstellt. Um Aktionen zu erstellen, kannst Du eigenen Code schreiben, der mit Deinem Repository auf die gewünschte Weise interagiert und dabei beispielsweise in die APIs von GitHub Enterprise Server und beliebige öffentlich zugänglichen Drittanbieter-APIs integriert. Mit einer Aktion können Sie beispielsweise npm-Module veröffentlichen, SMS-Nachrichten bei dringenden Problemen senden oder produktionsreifen Code bereitstellen. For more information, see "Creating actions."
CircleCI kann Workflows mit YAML-Ankern und Aliasen wiederverwenden. GitHub Actions unterstützen den üblichen Bedarf an Wiederverwendbarkeit durch Build-Matrizen. For more information about build matrixes, see "Managing complex workflows."
Docker-Images verwenden
Sowohl CircleCI als auch GitHub Actions können Schritte innerhalb eines Docker-Images ausführen.
CircleCI stellt eine Reihe von vordefinierten Images mit üblichen Abhängigkeiten zur Verfügung. Diese Images haben circleci
als USER
gesetzt, was zu Konflikten mit GitHub Actions führt.
Wir empfehlen Dir, von vordefinierten CircleCI-Images zu wegzugehen, wenn Du zu GitHub Actions migrierst. In vielen Fällen kannst Du die zusätzlich benötigten Abhängigkeiten mithilfe von Aktionen installieren.
Weitere Informationen über das Docker-Dateisystem findest Du unter „Virtuelle Umgebungen für GitHub Enterprise Server-gehostete Runner“. For more information about the tools and packages available on
GitHub-hosted virtual environments, see "Specifications for GitHub-hosted runners".
Variablen und Geheimnisse verwenden
CircleCI und GitHub Actions unterstützen das Setzen von Umgebungsvariablen in der Konfigurationsdatei und das Erstellen von Geheimnissen mit der Benutzeroberfläche von entweder CircleCI oder GitHub Enterprise Server.
Weitere Informationen findest Du unter „Umgebungsvariablen verwenden“ und „Verschlüsselte Geheimnisse erstellen und verwenden“.
Im Cache zwischenspeichern
CircleCI und GitHub Actions bieten in der Konfigurationsdatei eine Methode an, um Dateien manuell im Cache zwischenzuspeichern.
Nachfolgend ein Beispiel für die Syntax in jedem System.
CircleCI | GitHub Actions |
---|---|
|
|
GitHub Actions caching is only applicable for repositories hosted on GitHub.com. Weitere Informationen findest Du unter „Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern“.
GitHub Actions hat kein Äquivalent zum „Docker Layer Caching“ („DLC“, im Cache auf Docker-Ebene zwischenspeichern).
Daten zwischen Jobs persistieren
Sowohl CircleCI als auch GitHub Actions bieten Mechanismen für die Persistierung von Daten zwischen Jobs.
Nachfolgend siehst Du ein Beispiel in der Konfigurationssyntax von CircleCI und GitHub Actions.
CircleCI | GitHub Actions |
---|---|
|
|
Weitere Informationen findest Du unter „Workflow-Daten mittels Artefakten persistieren“.
Datenbanken und Service-Container verwenden
Mit beiden Systemen kannst Du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.
In CircleCI ist das erste in der config.yaml aufgelistete Image, das primäre Image, welches benutzt wird, um Befehle auszuführen. GitHub Actions verwendet explizite Abschnitte: container
für den primären Container und zusätzliche Container aufgelistet in services
.
Nachfolgend siehst Du ein Beispiel in der Konfigurationssyntax von CircleCI und GitHub Actions.
CircleCI | GitHub Actions |
---|---|
|
|
Weitere Informationen findest Du unter „Informationen zu Servicecontainern“.
Vollständiges Beispiel
Nachfolgend siehst Du ein Beispiel aus der realen Welt. Die linke Seite zeigt die tatsächliche config.yml unter CircleCI für das Repository thoughtbot/administrator. Die rechte Seite zeigt das Äquivalent unter GitHub Actions.
CircleCI | GitHub Actions |
---|---|
|
|