{"meta":{"title":"Migrieren von CircleCI zu GitHub Actions","intro":"GitHub Actions und CircleCI teilen mehrere Ähnlichkeiten in der Konfiguration, wodurch die Migration zu GitHub Actions relativ unkompliziert gestaltet wird.","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-circleci","title":"Migrieren von CircleCI"}],"documentType":"article"},"body":"# Migrieren von CircleCI zu GitHub Actions\n\nGitHub Actions und CircleCI teilen mehrere Ähnlichkeiten in der Konfiguration, wodurch die Migration zu GitHub Actions relativ unkompliziert gestaltet wird.\n\n## Einführung\n\nCircleCI und GitHub Actions ermöglichen Ihnen beide, Workflows zu erstellen, die Code automatisch bauen, testen, veröffentlichen, freigeben und bereitstellen. CircleCI und GitHub Actions teilen einige Ähnlichkeiten in der Workflowkonfiguration:\n\n* Workflow-Konfigurationsdateien werden in YAML geschrieben und im Repository gespeichert.\n* Workflows umfassen einen oder mehrere Jobs.\n* Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.\n* Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.\n\nWeitere Informationen finden Sie unter [Grundlegendes zu GitHub Actions](/de/actions/get-started/understand-github-actions).\n\n## Wesentliche Unterschiede\n\nBetrachte bei der Migration von CircleCI folgende Unterschiede:\n\n* Die automatische Testparallelität des CircleCI gruppiert die Tests automatisch nach benutzerdefinierten Regeln oder historischen Zeitinformationen. Diese Funktionalität ist nicht in GitHub Actions integriert.\n* 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 bei GitHub gehosteten Runnern finden Sie in [Gehostete Runnerreferenz auf GitHub](/de/actions/reference/runners/github-hosted-runners#docker-container-filesystem).\n\n## Migration von Workflows und Jobs\n\nBei CircleCI werden Workflows (`workflows`) in der Datei *config.yml* definiert. Dadurch lassen sich mehrere Workflows konfigurieren.\nGitHub erfordert eine Workflowdatei pro Workflow und erfordert daher nicht, dass Sie deklarieren `workflows`. Für jeden in *config.yml* konfigurierten Workflow muss eine neue Workflowdatei erstellt werden.\n\nSowohl CircleCI als auch GitHub Actions konfigurieren `jobs` in der Konfigurationsdatei mit einer ähnlichen Syntax. Wenn Sie in Ihrem CircleCI-Workflow Abhängigkeiten zwischen Jobs mithilfe von `requires` konfigurieren, können Sie die äquivalente GitHub Actions`needs`-Syntax verwenden. Weitere Informationen finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds).\n\n## „Orbs“ (Gestirne) zu Aktionen migrieren\n\nSowohl CircleCI als auch GitHub Actions bieten einen Mechanismus, um Aufgaben in einem Workflow wiederzuverwenden und zu teilen. CircleCI verwendet ein Konzept namens „Orbs“, das in YAML geschrieben ist, um Aufgaben bereitzustellen, die Benutzer in einem Workflow wiederverwenden können.\nGitHub Actions verfügt über leistungsstarke und flexible wiederverwendbare Komponenten, die als Aktionen bezeichnet werden, die Sie entweder mit JavaScript-Dateien oder Docker-Images erstellen. Sie können Aktionen erstellen, indem Sie benutzerdefinierten Code schreiben, der auf beliebige Weise mit Ihrem Repository interagiert, einschließlich der Integration mit GitHubden APIs von Drittanbietern und jeder öffentlich verfügbaren Drittanbieter-API. Beispielsweise kann eine Aktion npm-Module veröffentlichen, SMS-Warnungen senden, wenn dringende Probleme erstellt werden, oder produktionsbereiten Code bereitstellen. Weitere Informationen finden Sie unter [Wiederverwenden von Automatisierungen](/de/actions/how-tos/reuse-automations).\n\nCircleCI kann Workflows mit YAML-Ankern und Aliasen wiederverwenden.\nGitHub Actions unterstützt YAML-Anker und Aliase zur Wiederverwendbarkeit und stellt auch Matrizen für die Ausführung von Aufträgen mit unterschiedlichen Konfigurationen bereit. Weitere Informationen zu Matrizen findest du unter [Varianten von Aufgaben in einem Workflow ausführen](/de/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations).\n\n## Docker-Images verwenden\n\nSowohl CircleCI als auch GitHub Actions unterstützen die Ausführung von Schritten in einem Docker-Image.\n\nCircleCI stellt eine Reihe von vordefinierten Images mit üblichen Abhängigkeiten zur Verfügung. Bei diesen Bildern ist `USER` auf `circleci` gesetzt, was zu Konflikten mit der Berechtigung GitHub Actions führt.\n\nWir empfehlen, bei der Migration zu GitHub Actions nicht mehr die vorgefertigten Images von CircleCI zu verwenden. In vielen Fällen kannst du die zusätzlich benötigten Abhängigkeiten mithilfe von Aktionen installieren.\n\nWeitere Informationen zum Docker-Dateisystem findest du unter [Gehostete Runnerreferenz auf GitHub](/de/actions/reference/runners/github-hosted-runners#docker-container-filesystem).\n\nWeitere Informationen zu den Tools und Paketen, die auf GitHubgehosteten Runner-Images verfügbar sind, finden Sie unter [Von GitHub gehostete Runner](/de/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images).\n\n## Variablen und Geheimnisse verwenden\n\nCircleCI und GitHub Actions unterstützen das Festlegen von Variablen in der Konfigurationsdatei und das Erstellen von Geheimnissen über die CircleCI- oder GitHub-UI.\n\nWeitere Informationen findest du unter [Referenz für Variablen](/de/actions/reference/workflows-and-actions/variables#default-environment-variables) und [Verwenden von Geheimnissen in GitHub-Aktionen](/de/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\n## Caching\n\nCircleCI und GitHub Actions eine Methode zum manuellen Zwischenspeichern von Dateien in der Konfigurationsdatei bereitstellen.\n\nNachfolgend ein Beispiel für die Syntax in jedem System.\n\n### CircleCI-Syntax für das Zwischenspeichern\n\n```yaml\n- restore_cache:\n    keys:\n      - v1-npm-deps-{{ checksum \"package-lock.json\" }}\n      - v1-npm-deps-\n```\n\n### GitHub Actions Syntax für die Zwischenspeicherung\n\n```yaml\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\nGitHub Actions hat kein Äquivalent zu CircleCIs Docker Layer Caching (DLC).\n\n## Persistieren von Daten zwischen Jobs\n\nSowohl CircleCI als auch GitHub Actions bieten Möglichkeiten, Daten zwischen Jobs zu speichern.\n\nNachfolgend finden Sie ein Beispiel in CircleCI- und GitHub Actions-Konfigurationssyntax.\n\n### CircleCI-Syntax zum Beibehalten von Daten zwischen Aufträgen\n\n```yaml\n- persist_to_workspace:\n    root: workspace\n    paths:\n      - math-homework.txt\n\n...\n\n- attach_workspace:\n    at: /tmp/workspace\n```\n\n### GitHub Actions Syntax zum Beibehalten von Daten zwischen Aufträgen\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...\n\n- name: Download math result for job 1\n  uses: actions/download-artifact@v5\n  with:\n    name: homework\n```\n\nWeitere Informationen finden Sie unter [Speichern und Freigeben von Daten mit Workflowartefakten](/de/actions/tutorials/store-and-share-data).\n\n## Datenbanken und Service-Container verwenden\n\nMit beiden Systemen kannst du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.\n\nIn CircleCI ist das erste in der Datei *config.yaml* aufgelistete Image das primäre Image, welches benutzt wird, um Befehle auszuführen.\nGitHub Actions verwendet explizite Abschnitte: Verwenden Sie `container` für den primären Container und listen Sie zusätzliche Container in `services` auf.\n\nNachfolgend finden Sie ein Beispiel in CircleCI- und GitHub Actions-Konfigurationssyntax.\n\n### CircleCI-Syntax für die Verwendung von Datenbanken und Dienstcontainern\n\n```yaml\n---\nversion: 2.1\n\njobs:\n\n  ruby-26:\n    docker:\n      - image: circleci/ruby:2.6.3-node-browsers-legacy\n        environment:\n          PGHOST: localhost\n          PGUSER: administrate\n          RAILS_ENV: test\n      - image: postgres:10.1-alpine\n        environment:\n          POSTGRES_USER: administrate\n          POSTGRES_DB: ruby26\n          POSTGRES_PASSWORD: \"\"\n\n    working_directory: ~/administrate\n\n    steps:\n      - checkout\n\n      # Bundle install dependencies\n      - run: bundle install --path vendor/bundle\n\n      # Wait for DB\n      - run: dockerize -wait tcp://localhost:5432 -timeout 1m\n\n      # Setup the environment\n      - run: cp .sample.env .env\n\n      # Setup the database\n      - run: bundle exec rake db:setup\n\n      # Run the tests\n      - run: bundle exec rake\n\nworkflows:\n  version: 2\n  build:\n    jobs:\n      - ruby-26\n...\n\n- attach_workspace:\n    at: /tmp/workspace\n```\n\n### GitHub Actions Syntax für die Verwendung von Datenbanken und Dienstcontainern\n\n<!-- markdownlint-disable search-replace -->\n\n```yaml\nname: Containers\n\non: [push]\n\njobs:\n  build:\n\n    runs-on: ubuntu-latest\n    container: circleci/ruby:2.6.3-node-browsers-legacy\n\n    env:\n      PGHOST: postgres\n      PGUSER: administrate\n      RAILS_ENV: test\n\n    services:\n      postgres:\n        image: postgres:10.1-alpine\n        env:\n          POSTGRES_USER: administrate\n          POSTGRES_DB: ruby25\n          POSTGRES_PASSWORD: \"\"\n        ports:\n          - 5432:5432\n        # Add a health check\n        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5\n\n    steps:\n      # This Docker file changes sets USER to circleci instead of using the default user, so we need to update file permissions for this image to work on GH Actions.\n      # See https://docs.github.com/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem\n\n      - name: Setup file system permissions\n        run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp\n      - uses: actions/checkout@v6\n      - name: Install dependencies\n        run: bundle install --path vendor/bundle\n      - name: Setup environment configuration\n        run: cp .sample.env .env\n      - name: Setup database\n        run: bundle exec rake db:setup\n      - name: Run tests\n        run: bundle exec rake\n```\n\n<!-- markdownlint-enable search-replace -->\n\nWeitere Informationen finden Sie unter [Kommunizieren mit Docker-Dienstcontainern](/de/actions/tutorials/use-containerized-services/use-docker-service-containers).\n\n## Vollständiges Beispiel\n\nNachfolgend 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](https://github.com/thoughtbot/administrate) gezeigt. Rechts wird das GitHub Actions Äquivalent angezeigt.\n\n### Vollständiges Beispiel für CircleCI\n\n```yaml\n---\nversion: 2.1\n\ncommands:\n  shared_steps:\n    steps:\n      - checkout\n\n      # Restore Cached Dependencies\n      - restore_cache:\n          name: Restore bundle cache\n          key: administrate-{{ checksum \"Gemfile.lock\" }}\n\n      # Bundle install dependencies\n      - run: bundle install --path vendor/bundle\n\n      # Cache Dependencies\n      - save_cache:\n          name: Store bundle cache\n          key: administrate-{{ checksum \"Gemfile.lock\" }}\n          paths:\n            - vendor/bundle\n\n      # Wait for DB\n      - run: dockerize -wait tcp://localhost:5432 -timeout 1m\n\n      # Setup the environment\n      - run: cp .sample.env .env\n\n      # Setup the database\n      - run: bundle exec rake db:setup\n\n      # Run the tests\n      - run: bundle exec rake\n\ndefault_job: &default_job\n  working_directory: ~/administrate\n  steps:\n    - shared_steps\n    # Run the tests against multiple versions of Rails\n    - run: bundle exec appraisal install\n    - run: bundle exec appraisal rake\n\njobs:\n  ruby-25:\n    <<: *default_job\n    docker:\n      - image: circleci/ruby:2.5.0-node-browsers\n        environment:\n          PGHOST: localhost\n          PGUSER: administrate\n          RAILS_ENV: test\n      - image: postgres:10.1-alpine\n        environment:\n          POSTGRES_USER: administrate\n          POSTGRES_DB: ruby25\n          POSTGRES_PASSWORD: \"\"\n\n  ruby-26:\n    <<: *default_job\n    docker:\n      - image: circleci/ruby:2.6.3-node-browsers-legacy\n        environment:\n          PGHOST: localhost\n          PGUSER: administrate\n          RAILS_ENV: test\n      - image: postgres:10.1-alpine\n        environment:\n          POSTGRES_USER: administrate\n          POSTGRES_DB: ruby26\n          POSTGRES_PASSWORD: \"\"\n\nworkflows:\n  version: 2\n  multiple-rubies:\n    jobs:\n      - ruby-26\n      - ruby-25\n```\n\n### Vollständiges Beispiel für GitHub Actions\n\n```yaml\n# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.\n# Sie werden von einem Drittanbieter bereitgestellt und unterliegen\n# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support\n# Onlinedokumentation.\n\n# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.\n# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.\n# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.\n\nname: Containers\n\non: [push]\n\njobs:\n  build:\n\n    strategy:\n      matrix:\n        ruby: ['2.5', '2.6.3']\n\n    runs-on: ubuntu-latest\n\n    env:\n      PGHOST: localhost\n      PGUSER: administrate\n      RAILS_ENV: test\n\n    services:\n      postgres:\n        image: postgres:10.1-alpine\n        env:\n          POSTGRES_USER: administrate\n          POSTGRES_DB: ruby25\n          POSTGRES_PASSWORD: \"\"\n        ports:\n          - 5432:5432\n        # Add a health check\n        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5\n\n    steps:\n      - uses: actions/checkout@v6\n      - name: Setup Ruby\n        uses: eregon/use-ruby-action@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n        with:\n          ruby-version: ${{ matrix.ruby }}\n      - name: Cache dependencies\n        uses: actions/cache@v4\n        with:\n          path: vendor/bundle\n          key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}\n      - name: Install postgres headers\n        run: |\n          sudo apt-get update\n          sudo apt-get install libpq-dev\n      - name: Install dependencies\n        run: bundle install --path vendor/bundle\n      - name: Setup environment configuration\n        run: cp .sample.env .env\n      - name: Setup database\n        run: bundle exec rake db:setup\n      - name: Run tests\n        run: bundle exec rake\n      - name: Install appraisal\n        run: bundle exec appraisal install\n      - name: Run appraisal\n        run: bundle exec appraisal rake\n```"}