{"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 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:\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/learn-github-actions/understanding-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 in GitHub Actions nicht eingebaut.\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 über das Docker-Dateisystem auf von GitHub gehosteten Runnern findest du unter [Von GitHub gehostete Runner](/de/actions/using-github-hosted-runners/about-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. Da GitHub eine Workflowdatei pro Workflow benötigt, musst du `workflows` nicht deklarieren. 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 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 finden Sie unter [Workflowsyntax für GitHub Actions](/de/actions/using-workflows/workflow-syntax-for-github-actions#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 weiterzugeben. CircleCI verwendet ein Konzept namens „Orbs“, das in YAML geschrieben ist, um Aufgaben bereitzustellen, die Benutzer in einem Workflow wiederverwenden können. GitHub Actions hat mächtige und flexible wiederverwendbare Komponenten namens Aktionen, die man entweder mit JavaScript-Dateien oder mit Docker-Images erstellt. Zum Erstellen von Aktionen kannst du benutzerdefinierten Code schreiben, der mit deinem Repository auf die gewünschte Weise interagiert, z. B. mit APIs von GitHub und beliebigen öffentlich zugänglichen Drittanbieter-APIs integriert wird. 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/creating-actions).\n\nCircleCI kann Teile von Workflows mit YAML-Ankern und -Aliasen wiederverwenden. GitHub Actions unterstützt YAML-Anker und -Aliase für die Wiederverwendbarkeit und stellt außerdem Matrizen zum Ausführen von Aufträgen mit unterschiedlichen Konfigurationen bereit. Weitere Informationen zu Matrizen findest du unter [Varianten von Aufgaben in einem Workflow ausführen](/de/actions/using-jobs/using-a-matrix-for-your-jobs).\n\n## Docker-Images verwenden\n\nSowohl CircleCI als auch GitHub Actions können Schritte innerhalb eines Docker-Images ausführen.\n\nCircleCI 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.\n\nWir empfehlen dir, von den vorgenerierten CircleCI-Images Abstand zu nehmen, wenn du zu GitHub Actions migrierst. 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 [Von GitHub gehostete Runner](/de/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem).\n\nWeitere Informationen zu den Tools und Paketen, die in von GitHub gehosteten Runnerimages verfügbar sind, findest du unter [Von GitHub gehostete Runner](/de/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software).\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 mit der Benutzeroberfläche von CircleCI oder GitHub.\n\nWeitere Informationen findest du unter [Referenz für Variablen](/de/actions/reference/variables-reference#default-environment-variables) und [Verwenden von Geheimnissen in GitHub-Aktionen](/de/actions/security-guides/using-secrets-in-github-actions).\n\n## Caching\n\nCircleCI und GitHub Actions bieten in der Konfigurationsdatei eine Methode an, um Dateien manuell im Cache zwischenzuspeichern.\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 Docker Layer Caching (DLC) von CircleCI.\n\n## Persistieren von Daten zwischen Jobs\n\nSowohl CircleCI als auch GitHub Actions bieten Mechanismen für die Persistierung von Daten zwischen Jobs.\n\nNachfolgend siehst du ein Beispiel in der Konfigurationssyntax von CircleCI und GitHub Actions.\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/using-workflows/storing-workflow-data-as-artifacts).\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. GitHub Actions verwendet explizite Abschnitte: verwende `container` für den primären Container, und liste zusätzliche Container in `services` auf.\n\nNachfolgend siehst du ein Beispiel in der Konfigurationssyntax von CircleCI und GitHub Actions.\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/using-containerized-services/about-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 Äquivalent von GitHub Actions 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```"}