Einführung
Sowohl GitLab CI/CD als auch GitHub Actions erlauben es Ihnen, Workflows zu erstellen, mit denen Code automatisch erstellt, getestet, veröffentlicht, freigegeben und bereitgestellt wird. GitLab CI/CD und GitHub Actions haben einige Ähnlichkeiten in der Workflow-Konfiguration:
- Workflow-Konfigurationsdateien werden in YAML geschrieben und im Code-Repository gespeichert.
- Workflows umfassen einen oder mehrere Jobs.
- Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
- Aufträge können entweder auf verwalteten oder auf selbstgehosteten Computern ausgeführt werden.
Es gibt einige Unterschiede, und in diesem Leitfaden kannst du dich mit den wichtigsten Unterschieden vertraut machen, damit du deinen Workflow zu GitHub Actions migrieren kannst.
Aufträge
Aufträge in GitLab CI/CD sind Aufträgen in GitHub Actions sehr ähnlich. In beiden Systemen haben Jobs folgende Merkmale:
- Aufträge enthalten eine Reihe von Schritten oder Skripts, die sequenziell ausgeführt werden.
- Aufträge können auf separaten Computern oder in separaten Containern ausgeführt werden.
- Jobs werden standardmäßig parallel ausgeführt, können aber so konfiguriert werden, dass sie sequentiell laufen.
Du kannst ein Skript oder einen Shellbefehl in einem Auftrag ausführen. In GitLab CI/CD werden Skriptschritte mithilfe des Schlüssels script angegeben. In GitHub Actions sind alle Skripts mit dem Schlüssel run spezifiziert.
Nachfolgend ein Beispiel für die Syntax in jedem System.
GitLab CI/CD-Syntax für Aufträge
job1:
variables:
GIT_CHECKOUT: "true"
script:
- echo "Run your script here"
GitHub Actions-Syntax für Aufträge
jobs:
job1:
steps:
- uses: actions/checkout@v4
- run: echo "Run your script here"
Runner
Runner sind Computer, auf denen die Aufträge ausgeführt werden. Sowohl GitLab CI/CD als auch GitHub Actions bieten verwaltete und selbstgehostete Varianten von Runnern an. In GitLab CI/CD werden tags dazu verwendet, Aufträge auf verschiedenen Plattformen auszuführen, während sie in GitHub Actions mit dem Schlüssel runs-on ausgeführt werden.
Nachfolgend ein Beispiel für die Syntax in jedem System.
GitLab CI/CD-Syntax für Runner
windows_job:
tags:
- windows
script:
- echo Hello, %USERNAME%!
linux_job:
tags:
- linux
script:
- echo "Hello, $USER!"
GitHub Actions-Syntax für Runner
windows_job:
runs-on: windows-latest
steps:
- run: echo Hello, %USERNAME%!
linux_job:
runs-on: ubuntu-latest
steps:
- run: echo "Hello, $USER!"
Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Docker-Images
Sowohl GitLab CI/CD als auch GitHub Actions unterstützen die Ausführung von Aufträgen in einem Docker-Image. In GitLab CI/CD werden Docker-Images mit einem image-Schlüssel definiert, während sie in GitHub Actions mit dem Schlüssel container definiert werden.
Nachfolgend ein Beispiel für die Syntax in jedem System.
GitLab CI/CD-Syntax für Docker-Images
my_job:
image: node:20-bookworm-slim
GitHub Actions-Syntax für Docker-Images
jobs:
my_job:
container: node:20-bookworm-slim
Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Bedingungs- und Ausdruckssyntax
In GitLab CI/CD wird anhand von rules festgestellt, ob ein Auftrag für eine bestimmte Bedingung ausgeführt wird. Von GitHub Actions wird mithilfe des Schlüsselworts if sichergestellt, dass ein Auftrag nur dann ausgeführt wird, wenn eine Bedingung erfüllt wird.
Nachfolgend ein Beispiel für die Syntax in jedem System.
GitLab CI/CD-Syntax für Bedingungen und Ausdrücke
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
GitHub Actions-Syntax für Bedingungen und Ausdrücke
jobs:
deploy_prod:
if: contains( github.ref, 'master')
runs-on: ubuntu-latest
steps:
- run: echo "Deploy to production server"
Weitere Informationen findest du unter Auswerten von Ausdrücken in Workflows und Aktionen.
Abhängigkeiten zwischen Jobs
Sowohl mit GitLab CI/CD als auch mit GitHub Actions kannst du Abhängigkeiten für einen Job festlegen. In beiden Systemen werden Aufträge standardmäßig parallel ausgeführt, aber Auftragsabhängigkeiten in GitHub Actions können explizit mit dem Schlüssel needs angegeben werden. In GitLab CI/CD existiert auch ein Konzept von stages. Hier werden Aufträge in einer Phase gleichzeitig ausgeführt, aber die nächste Phase beginnt erst dann, wenn alle Aufträge aus der vorherigen Phase abgeschlossen sind. Dieses Szenario kannst du in GitHub Actions mit dem Schlüssel needs nachbilden.
Nachfolgend ein Beispiel für die Syntax in jedem System. Die Workflows beginnen mit zwei Aufträgen namens build_a und build_b, die parallel ausgeführt werden. Nach Abschluss dieser Aufträge wird ein weiterer Auftrag ausgeführt, der mit der Bezeichnung test_ab benannt ist. Schließlich wird, nach Abschluss von test_ab, der Auftrag deploy_ab ausgeführt.
GitLab CI/CD-Syntax für Abhängigkeiten zwischen Aufträgen
stages:
- build
- test
- deploy
build_a:
stage: build
script:
- echo "This job will run first."
build_b:
stage: build
script:
- echo "This job will run first, in parallel with build_a."
test_ab:
stage: test
script:
- echo "This job will run after build_a and build_b have finished."
deploy_ab:
stage: deploy
script:
- echo "This job will run after test_ab is complete"
GitHub Actions-Syntax für Abhängigkeiten zwischen Aufträgen
jobs:
build_a:
runs-on: ubuntu-latest
steps:
- run: echo "This job will be run first."
build_b:
runs-on: ubuntu-latest
steps:
- run: echo "This job will be run first, in parallel with build_a"
test_ab:
runs-on: ubuntu-latest
needs: [build_a,build_b]
steps:
- run: echo "This job will run after build_a and build_b have finished"
deploy_ab:
runs-on: ubuntu-latest
needs: [test_ab]
steps:
- run: echo "This job will run after test_ab is complete"
Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
Planen von Workflows
Sowohl GitLab CI/CD als auch GitHub Actions ermöglichen es Ihnen, Workflows in einem bestimmten Intervall auszuführen. In GitLab CI/CD werden Pipelinepläne mit der Benutzeroberfläche konfiguriert, während du in GitHub Actions einen Workflow in einem geplanten Intervall mit dem Schlüssel „on“ auslösen kannst.
Weitere Informationen findest du unter Ereignisse zum Auslösen von Workflows.
Variablen und Geheimnisse
GitLab CI/CD und GitHub Actions unterstützen das Festlegen von Variablen in der Pipeline- oder Workflowkonfigurationsdatei und das Erstellen von Geheimnissen mithilfe der Benutzeroberfläche von GitLab oder GitHub.
Weitere Informationen finden Sie unter Speichern von Informationen in Variablen und unter Verwenden von Geheimnissen in GitHub-Aktionen.
Caching
GitLab CI/CD und GitHub Actions stellen in der Konfigurationsdatei eine Methode zum manuellen Zwischenspeichern von Workflowdateien bereit.
Nachfolgend ein Beispiel für die Syntax in jedem System.
GitLab CI/CD-Syntax für das Zwischenspeichern
image: node:latest
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- .npm/
before_script:
- npm ci --cache .npm --prefer-offline
test_async:
script:
- node ./specs/start.js ./specs/async.spec.js
GitHub Actions-Syntax für das Zwischenspeichern
jobs:
test_async:
runs-on: ubuntu-latest
steps:
- name: Cache node modules
uses: actions/cache@v3
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
restore-keys: v1-npm-deps-
Artifacts
Sowohl von GitLab CI/CD als auch von GitHub Actions können Dateien und Verzeichnisse hochgeladen werden, die von einem Auftrag als Artefakte erstellt wurden. In GitHub Actions können Artefakte dazu verwendet werden, Daten über mehrere Aufträge hinweg beizubehalten.
Nachfolgend ein Beispiel für die Syntax in jedem System.
GitLab CI/CD-Syntax für Artefakte
script:
artifacts:
paths:
- math-homework.txt
GitHub Actions-Syntax für Artefakte
- name: Upload math result for job 1
uses: actions/upload-artifact@v4
with:
name: homework
path: math-homework.txt
Weitere Informationen findest du unter Speichern und Freigeben von Daten aus einem Workflow.
Datenbanken und Dienstcontainer
Mit beiden Systemen kannst du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.
In GitLab CI/CD wird ein Container für den Auftrag mit dem Schlüssel image angegeben, während von GitHub Actions der Schlüssel container verwendet wird. In beiden Systemen werden zusätzliche Dienstcontainer mit dem Schlüssel services angegeben.
Nachfolgend ein Beispiel für die Syntax in jedem System.
GitLab CI/CD-Syntax für Datenbanken und Dienstcontainer
container-job:
variables:
POSTGRES_PASSWORD: postgres
# The hostname used to communicate with the
# PostgreSQL service container
POSTGRES_HOST: postgres
# The default PostgreSQL port
POSTGRES_PORT: 5432
image: node:20-bookworm-slim
services:
- postgres
script:
# Performs a clean installation of all dependencies
# in the `package.json` file
- npm ci
# Runs a script that creates a PostgreSQL client,
# populates the client with data, and retrieves data
- node client.js
tags:
- docker
GitHub Actions-Syntax für Datenbanken und Dienstcontainer
jobs:
container-job:
runs-on: ubuntu-latest
container: node:20-bookworm-slim
services:
postgres:
image: postgres
env:
POSTGRES_PASSWORD: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v4
# Performs a clean installation of all dependencies
# in the `package.json` file
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
# Runs a script that creates a PostgreSQL client,
# populates the client with data, and retrieves data
run: node client.js
env:
# The hostname used to communicate with the
# PostgreSQL service container
POSTGRES_HOST: postgres
# The default PostgreSQL port
POSTGRES_PORT: 5432
Weitere Informationen findest du unter Informationen zu Service-Containern.