Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der 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 Grundlegendes zu 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. Viele dieser Probleme lassen sich vermeiden, indem die
USER
-Anweisung nicht in Dockerfile verwendet wird. Weitere Informationen zum Docker-Dateisystem auf von GitHub Enterprise Server gehosteten Runnern findest du unter Informationen zu von GitHub gehostete Runnern.
Workflows und Jobs migrieren
Bei CircleCI werden Workflows (workflows
) in der Datei config.yml definiert. Dadurch lassen sich mehrere Workflows konfigurieren. Da GitHub Enterprise Server eine Workflowdatei pro Workflow benötigt, müssen keine Workflows (workflows
) deklariert werden. Für jeden in config.yml konfigurierten Workflow muss eine neue Workflowdatei erstellt werden.
Sowohl bei CircleCI als auch bei GitHub Actions werden Aufträge (jobs
) in der Konfigurationsdatei mit einer ähnlichen Syntax konfiguriert. Wenn du Abhängigkeiten zwischen Aufträgen mithilfe von requires
in deinem CircleCI-Workflow konfigurierst, kannst du die entsprechende needs
-Syntax von GitHub Actions verwenden. Weitere Informationen findest du unter Workflowsyntax 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. Beispielsweise kann eine Aktion npm-Module veröffentlichen, SMS-Warnungen senden, wenn dringende Probleme erstellt werden, oder produktionsbereiten Code bereitstellen. Weitere Informationen findest du unter Erstellen von Aktionen.
CircleCI kann Workflows mit YAML-Ankern und Aliasen wiederverwenden. GitHub Actions unterstützt die gängigsten Anforderungen im Hinblick auf die Wiederverwendbarkeit durch den Einsatz von Matrizen. Weitere Informationen zu Matrizen findest du unter Verwenden von Matrizen für deine Aufträge.
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. Bei diesen Images ist USER
auf circleci
festgelegt. Dies führt zu Berechtigungskonflikten mit GitHub Actions.
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 zum Docker-Dateisystem findest du unter Informationen zu von GitHub gehostete Runnern.
Weitere Informationen zu den Tools und Paketen, die in von GitHub-gehosteten Runnerimages verfügbar sind, findest du unter Informationen zu von GitHub gehostete Runnern.
Variablen und Geheimnisse verwenden
CircleCI und GitHub Actions unterstützen das Setzen von Variablen in der Konfigurationsdatei und das Erstellen von Geheimnissen mit der Benutzeroberfläche von entweder CircleCI oder GitHub Enterprise Server.
Weitere Informationen findest du unter Variablen und unter Verschlüsselte Geheimnisse.
Caching
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-Aktionen |
---|---|
|
|
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-Aktionen |
---|---|
|
|
Weitere Informationen findest du unter Speichern von Workflowdaten als Artefakte.
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 Datei config.yaml aufgelistete Image das primäre Image, welches benutzt wird, um Befehle auszuführen. GitHub Actions verwendet explizite Abschnitte: verwende container
für den primären Container, und liste zusätzliche Container in services
auf.
Nachfolgend siehst du ein Beispiel in der Konfigurationssyntax von CircleCI und GitHub Actions.
CircleCI | GitHub-Aktionen |
---|---|
|
|
Weitere Informationen findest du unter Informationen zu Service-Containern.
Vollständiges Beispiel
Nachfolgend siehst du ein Beispiel aus der realen Welt. Auf der linken Seite ist die tatsächliche CircleCI-Datei config.yml für das Repository thoughtbot/administrator gezeigt. Die rechte Seite zeigt das Äquivalent unter GitHub Actions.
CircleCI | GitHub-Aktionen |
---|---|
|
|