{"meta":{"title":"Migrieren von GitLab CI/CD zu GitHub Actions","intro":"GitHub Actions und GitLab CI/CD haben mehrere Gemeinsamkeiten bezüglich der Konfiguration, was die Migration zu GitHub Actions relativ einfach macht.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/tutorials","title":"Anleitungen"},{"href":"/de/actions/tutorials/migrate-to-github-actions","title":"Migrieren zu GitHub Actions"},{"href":"/de/actions/tutorials/migrate-to-github-actions/manual-migrations","title":"Manuelles Migrieren"},{"href":"/de/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-gitlab-cicd","title":"Migrieren von GitLab CI/CD"}],"documentType":"article"},"body":"# Migrieren von GitLab CI/CD zu GitHub Actions\n\nGitHub Actions und GitLab CI/CD haben mehrere Gemeinsamkeiten bezüglich der Konfiguration, was die Migration zu GitHub Actions relativ einfach macht.\n\n## Einführung\n\nSowohl 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:\n\n* Workflow-Konfigurationsdateien werden in YAML geschrieben und im Code-Repository gespeichert.\n* Workflows umfassen einen oder mehrere Jobs.\n* Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.\n* Aufträge können entweder auf verwalteten oder auf selbstgehosteten Computern ausgeführt werden.\n\nEs 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.\n\n## Aufträge\n\nAufträge in GitLab CI/CD sind Aufträgen in GitHub Actions sehr ähnlich. In beiden Systemen haben Jobs folgende Merkmale:\n\n* Aufträge enthalten eine Reihe von Schritten oder Skripts, die sequenziell ausgeführt werden.\n* Aufträge können auf separaten Computern oder in separaten Containern ausgeführt werden.\n* Jobs werden standardmäßig parallel ausgeführt, können aber so konfiguriert werden, dass sie sequentiell laufen.\n\nDu 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.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### GitLab CI/CD-Syntax für Aufträge\n\n```yaml\njob1:\n  variables:\n    GIT_CHECKOUT: \"true\"\n  script:\n    - echo \"Run your script here\"\n```\n\n### GitHub Actions-Syntax für Aufträge\n\n```yaml\njobs:\n  job1:\n    steps:\n      - uses: actions/checkout@v5\n      - run: echo \"Run your script here\"\n```\n\n## Runner\n\nRunner 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.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### GitLab CI/CD-Syntax für Runners\n\n```yaml\nwindows_job:\n  tags:\n    - windows\n  script:\n    - echo Hello, %USERNAME%!\n\nlinux_job:\n  tags:\n    - linux\n  script:\n    - echo \"Hello, $USER!\"\n```\n\n### GitHub Actions-Syntax für Runner\n\n```yaml\nwindows_job:\n  runs-on: windows-latest\n  steps:\n    - run: echo Hello, %USERNAME%!\n\nlinux_job:\n  runs-on: ubuntu-latest\n  steps:\n    - run: echo \"Hello, $USER!\"\n```\n\nWeitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).\n\n## Docker Images\n\nSowohl 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.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### GitLab CI/CD-Syntax für Docker-Images\n\n```yaml\nmy_job:\n  image: node:20-bookworm-slim\n```\n\n### GitHub Actions-Syntax für Docker-Images\n\n```yaml\njobs:\n  my_job:\n    container: node:20-bookworm-slim\n```\n\nWeitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer).\n\n## Bedingungs- und Ausdruckssyntax\n\nIn GitLab CI/CD wird anhand von `rules` festgestellt, ob ein Auftrag für eine bestimmte Bedingung ausgeführt wird. GitHub Actions verwendet das Schlüsselwort `if`, um einen Auftrag nur auszuführen, wenn eine Bedingung erfüllt ist.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### GitLab CI/CD-Syntax für Bedingungen und Ausdrücke\n\n```yaml\ndeploy_prod:\n  stage: deploy\n  script:\n    - echo \"Deploy to production server\"\n  rules:\n    - if: '$CI_COMMIT_BRANCH == \"master\"'\n```\n\n### GitHub Actions-Syntax für Bedingungen und Ausdrücke\n\n```yaml\njobs:\n  deploy_prod:\n    if: contains( github.ref, 'master')\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to production server\"\n```\n\nWeitere Informationen finden Sie unter [Auswerten von Ausdrücken in Workflows und Aktionen](/de/actions/learn-github-actions/expressions).\n\n## Abhängigkeiten zwischen Jobs\n\nSowohl 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.\n\nNachfolgend 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.\n\n### GitLab CI/CD-Syntax für Abhängigkeiten zwischen Aufträgen\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"This job will run first.\"\n\nbuild_b:\n  stage: build\n  script:\n    - echo \"This job will run first, in parallel with build_a.\"\n\ntest_ab:\n  stage: test\n  script:\n    - echo \"This job will run after build_a and build_b have finished.\"\n\ndeploy_ab:\n  stage: deploy\n  script:\n    - echo \"This job will run after test_ab is complete\"\n```\n\n### GitHub Actions-Syntax für Abhängigkeiten zwischen Aufträgen\n\n```yaml\njobs:\n  build_a:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first.\"\n\n  build_b:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first, in parallel with build_a\"\n\n  test_ab:\n    runs-on: ubuntu-latest\n    needs: [build_a,build_b]\n    steps:\n      - run: echo \"This job will run after build_a and build_b have finished\"\n\n  deploy_ab:\n    runs-on: ubuntu-latest\n    needs: [test_ab]\n    steps:\n      - run: echo \"This job will run after test_ab is complete\"\n```\n\nWeitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds).\n\n## Planen von Workflows\n\nSowohl 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.\n\nWeitere Informationen finden Sie unter [Ereignisse zum Auslösen von Workflows](/de/actions/using-workflows/events-that-trigger-workflows#scheduled-events).\n\n## Variablen und Geheimnisse\n\nGitLab 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.\n\nWeitere Informationen findest du unter [Speichern von Informationen in Variablen](/de/actions/learn-github-actions/variables) und [Geheimnisse](/de/actions/security-for-github-actions/security-guides/about-secrets).\n\n## Caching\n\nGitLab CI/CD und GitHub Actions stellen in der Konfigurationsdatei eine Methode zum manuellen Zwischenspeichern von Workflowdateien bereit.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### GitLab CI/CD-Syntax zum Caching\n\n```yaml\nimage: node:latest\n\ncache:\n  key: $CI_COMMIT_REF_SLUG\n  paths:\n    - .npm/\n\nbefore_script:\n  - npm ci --cache .npm --prefer-offline\n\ntest_async:\n  script:\n    - node ./specs/start.js ./specs/async.spec.js\n```\n\n### GitHub Actions-Syntax für das Zwischenspeichern\n\n```yaml\njobs:\n  test_async:\n    runs-on: ubuntu-latest\n    steps:\n    - name: Cache node modules\n      uses: actions/cache@v4\n      with:\n        path: ~/.npm\n        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}\n        restore-keys: v1-npm-deps-\n```\n\n## Artefakte\n\nSowohl GitLab CI/CD als auch GitHub Actions können Dateien und Verzeichnisse, die in einem Auftrag erstellt wurden, als Artefakte hochladen. In GitHub Actions können Artefakte dazu verwendet werden, Daten über mehrere Aufträge hinweg beizubehalten.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### GitLab CI/CD-Syntax für Artefakte\n\n```yaml\nscript:\nartifacts:\n  paths:\n    - math-homework.txt\n```\n\n### GitHub Actions-Syntax für Artefakte\n\n```yaml\n- name: Upload math result for job 1\n  uses: actions/upload-artifact@v4\n  with:\n    name: homework\n    path: math-homework.txt\n```\n\nWeitere Informationen finden Sie unter [Speichern und Freigeben von Daten mit Workflowartefakten](/de/actions/using-workflows/storing-workflow-data-as-artifacts).\n\n## Datenbanken und Dienstcontainer\n\nMit beiden Systemen kannst du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.\n\nIn 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.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### GitLab CI/CD-Syntax für Datenbanken und Dienstcontainer\n\n```yaml\ncontainer-job:\n  variables:\n    POSTGRES_PASSWORD: postgres\n    # The hostname used to communicate with the\n    # PostgreSQL service container\n    POSTGRES_HOST: postgres\n    # The default PostgreSQL port\n    POSTGRES_PORT: 5432\n  image: node:20-bookworm-slim\n  services:\n    - postgres\n  script:\n    # Performs a clean installation of all dependencies\n    # in the `package.json` file\n    - npm ci\n    # Runs a script that creates a PostgreSQL client,\n    # populates the client with data, and retrieves data\n    - node client.js\n  tags:\n    - docker\n```\n\n### GitHub Actions-Syntax für Datenbanken und Dienstcontainer\n\n```yaml\njobs:\n  container-job:\n    runs-on: ubuntu-latest\n    container: node:20-bookworm-slim\n\n    services:\n      postgres:\n        image: postgres\n        env:\n          POSTGRES_PASSWORD: postgres\n\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v5\n\n      # Performs a clean installation of all dependencies\n      # in the `package.json` file\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Connect to PostgreSQL\n        # Runs a script that creates a PostgreSQL client,\n        # populates the client with data, and retrieves data\n        run: node client.js\n        env:\n          # The hostname used to communicate with the\n          # PostgreSQL service container\n          POSTGRES_HOST: postgres\n          # The default PostgreSQL port\n          POSTGRES_PORT: 5432\n```\n\nWeitere Informationen finden Sie unter [Kommunizieren mit Docker-Dienstcontainern](/de/actions/using-containerized-services/about-service-containers)."}