# Migrieren von GitLab CI/CD zu GitHub Actions

GitHub Actions und GitLab CI/CD teilen mehrere Konfigurationsähnlichkeiten, was die Migration zu GitHub Actions relativ einfach macht.

## Einführung

GitLab CI/CD und GitHub Actions beide ermöglichen es Ihnen, Workflows zu erstellen, die automatisch Code erstellen, testen, veröffentlichen, freigeben und bereitstellen. GitLab CI/CD und GitHub Actions teilen einige Ähnlichkeiten in der Workflowkonfiguration:

* 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 diese Anleitung zeigt Ihnen die wichtigsten Unterschiede, damit Sie Ihren Workflow zu GitHub Actions migrieren können.

## Aufträge

Jobs in GitLab CI/CD sind sehr ähnlich wie Aufträge in GitHub Actions. 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, werden alle Skripts mit dem `run` Schlüssel angegeben.

Nachfolgend ein Beispiel für die Syntax in jedem System.

### GitLab CI/CD-Syntax für Aufträge

```yaml
job1:
  variables:
    GIT_CHECKOUT: "true"
  script:
    - echo "Run your script here"
```

### GitHub Actions-Syntax für Aufträge

```yaml
jobs:
  job1:
    steps:
      - uses: actions/checkout@v6
      - 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 selbst gehostete Runner-Varianten. In GitLab CI/CD werden mit `tags` Jobs auf verschiedenen Plattformen ausgeführt, während dies in GitHub Actions mit dem Schlüsselwort `runs-on` erfolgt.

Nachfolgend ein Beispiel für die Syntax in jedem System.

### GitLab CI/CD-Syntax für Runners

```yaml
windows_job:
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

linux_job:
  tags:
    - linux
  script:
    - echo "Hello, $USER!"
```

### GitHub Actions-Syntax für Runner

```yaml
windows_job:
  runs-on: windows-latest
  steps:
    - run: echo Hello, %USERNAME%!

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER!"
```

Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idruns-on).

## Docker Images

Sowohl GitLab CI/CD als auch GitHub Actions unterstützen die Ausführung von Jobs in einem Docker-Image. In GitLab CI/CD werden Docker-Images mit einem `image` Schlüssel definiert, während GitHub Actions dies mit dem `container` Schlüssel erfolgt.

Nachfolgend ein Beispiel für die Syntax in jedem System.

### GitLab CI/CD-Syntax für Docker-Images

```yaml
my_job:
  image: node:20-bookworm-slim
```

### GitHub Actions Syntax für Docker-Images

```yaml
jobs:
  my_job:
    container: node:20-bookworm-slim
```

Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer).

## Bedingungs- und Ausdruckssyntax

In GitLab CI/CD wird anhand von `rules` festgestellt, ob ein Auftrag für eine bestimmte Bedingung ausgeführt wird.
GitHub Actions verwendet das `if` Schlüsselwort, um zu verhindern, dass ein Auftrag ausgeführt wird, es sei denn, eine Bedingung ist erfüllt.

Nachfolgend ein Beispiel für die Syntax in jedem System.

### GitLab CI/CD-Syntax für Bedingungen und Ausdrücke

```yaml
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

```yaml
jobs:
  deploy_prod:
    if: contains( github.ref, 'master')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production server"
```

Weitere Informationen finden Sie unter [Auswerten von Ausdrücken in Workflows und Aktionen](/de/actions/reference/workflows-and-actions/expressions).

## Abhängigkeiten zwischen Jobs

Sowohl GitLab CI/CD als auch GitHub Actions ermöglichen es Ihnen, Abhängigkeiten für einen Job festzulegen. In beiden Systemen werden Jobs standardmäßig parallel ausgeführt, aber Job-Abhä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. Sie können dieses Szenario in GitHub Actions mit der Taste `needs` nachstellen.

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

```yaml
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

```yaml
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 finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds).

## Planen von Workflows

Sowohl GitLab CI/CD als auch GitHub Actions ermöglichen es Ihnen, Workflows in einem festgelegten Intervall auszuführen. In GitLab CI/CD werden Pipeline-Zeitpläne über die Benutzeroberfläche konfiguriert, während Sie in GitHub Actions mit dem Schlüssel „on“ einen Workflow nach einem Zeitplan auslösen können.

Weitere Informationen finden Sie unter [Ereignisse zum Auslösen von Workflows](/de/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).

## Variablen und Geheimnisse

GitLab CI/CD und GitHub Actions unterstützen das Definieren von Variablen in der Pipeline- oder Workflow-Konfigurationsdatei sowie das Erstellen von Secrets über die GitLab- oder GitHub-Benutzeroberfläche.

Weitere Informationen findest du unter [Speichern von Informationen in Variablen](/de/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables) und [Geheimnisse](/de/actions/concepts/security/secrets).

## Caching

GitLab CI/CD und GitHub Actions stellt eine Methode in der Konfigurationsdatei bereit, um Workflowdateien manuell zwischenzuspeichern.

Nachfolgend ein Beispiel für die Syntax in jedem System.

### GitLab CI/CD-Syntax zum Caching

```yaml
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 zum Zwischenspeichern

```yaml
jobs:
  test_async:
    runs-on: ubuntu-latest
    steps:
    - name: Cache node modules
      uses: actions/cache@v4
      with:
        path: ~/.npm
        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
        restore-keys: v1-npm-deps-
```

## Artefakte

Sowohl GitLab CI/CD als auch GitHub Actions können Dateien und Verzeichnisse, die durch einen Job erstellt wurden, als Artefakte hochladen. In GitHub Actions können Artefakte verwendet werden, um Daten über mehrere Jobs hinweg beizubehalten.

Nachfolgend ein Beispiel für die Syntax in jedem System.

### GitLab CI/CD-Syntax für Artefakte

```yaml
script:
artifacts:
  paths:
    - math-homework.txt
```

### GitHub Actions Syntax für Artefakte

```yaml
- name: Upload math result for job 1
  uses: actions/upload-artifact@v4
  with:
    name: homework
    path: math-homework.txt
```

Weitere Informationen finden Sie unter [Speichern und Freigeben von Daten mit Workflowartefakten](/de/actions/tutorials/store-and-share-data).

## 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 `image` Schlüssel angegeben, während GitHub Actions der `container` Schlüssel 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

```yaml
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

```yaml
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@v6

      # 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 finden Sie unter [Kommunizieren mit Docker-Dienstcontainern](/de/actions/tutorials/use-containerized-services/use-docker-service-containers).