Diese Version von GitHub Enterprise wurde eingestellt am 2021-09-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Von CircleCI zu GitHub-Aktionen migrieren

GitHub-Aktionen und CircleCI haben mehrere Ähnlichkeiten in der Konfiguration, was die Migration zu GitHub-Aktionen relativ einfach macht.

Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.


Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.

Einführung

CircleCI 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:

  • Workflow-Konfigurationsdateien werden in YAML geschrieben und im Repository gespeichert.
  • Workflows umfassen einen oder mehrere Jobs.
  • Jobs beinhalten einen oder mehrere Schritte oder einzelne Befehle.
  • Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.

Weitere Informationen findest Du unter „Kernkonzepte für GitHub Actions“.

Wesentliche Unterschiede

Betrachte bei der Migration von CircleCI folgende Unterschiede:

  • 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.
  • Aktionen, die in Docker-Containern ausgeführt werden, sind sensibel für Berechtigungsprobleme, da Container eine andere Zuordnung von Benutzern haben. Du kannst viele dieser Probleme vermeiden, indem Du die Anweisung USER in Deinem Dockerfile nicht verwendest. For more information about the Docker filesystem on GitHub Enterprise Server-hosted runners, see "Virtual environments for GitHub Enterprise Server-hosted runners."

Workflows und Jobs migrieren

CircleCI definiert Workflows in der Datei config.yml, wodurch Du mehrere Workflows konfigurieren kannst. GitHub Enterprise Server benötigt pro Workflow eine Workflow-Datei und erfordert daher nicht Workflows zu deklarieren. Du musst für jeden Workflow, der in config.yml konfiguriert ist, eine neue Workflow-Datei erstellen.

Sowohl CircleCI als auch GitHub Actions konfigurieren Jobs in der Konfigurationsdatei, und das mit ähnlicher Syntax. Wenn Du Abhängigkeiten zwischen Jobs in Deinem CircleCI-Workflow mit requires konfigurierst, kannst Du in GitHub Actions die äquivalente Syntax needs verwenden. Weitere Informationen findest Du unter „Workflow-Syntax für GitHub Actions“.

„Orbs“ (Gestirne) zu Aktionen migrieren

Sowohl CircleCI als auch GitHub Actions bieten einen Mechanismus, um Aufgaben in einem Workflow wiederzuverwenden und weiterzugeben. CircleCI verwendet ein Konzept namens „Orbs“ (Gestirne), das in YAML geschrieben ist, um Aufgaben bereitzustellen, die man in einem Workflow wiederverwenden kann. GitHub Actions hat mächtige und flexible wiederverwendbare Komponenten namens Aktionen, die man entweder mit JavaScript-Dateien oder mit Docker-Images erstellt. Um Aktionen zu erstellen, kannst Du eigenen Code schreiben, der mit Deinem Repository auf die gewünschte Weise interagiert und dabei beispielsweise in die APIs von GitHub Enterprise Server und beliebige öffentlich zugänglichen Drittanbieter-APIs integriert. Mit einer Aktion können Sie beispielsweise npm-Module veröffentlichen, SMS-Nachrichten bei dringenden Problemen senden oder produktionsreifen Code bereitstellen. For more information, see "Creating actions."

CircleCI kann Workflows mit YAML-Ankern und Aliasen wiederverwenden. GitHub Actions unterstützen den üblichen Bedarf an Wiederverwendbarkeit durch Build-Matrizen. For more information about build matrixes, see "Managing complex workflows."

Docker-Images verwenden

Sowohl CircleCI als auch GitHub Actions können Schritte innerhalb eines Docker-Images ausführen.

CircleCI stellt eine Reihe von vordefinierten Images mit üblichen Abhängigkeiten zur Verfügung. Diese Images haben circleci als USER gesetzt, was zu Konflikten mit GitHub Actions führt.

Wir empfehlen Dir, von vordefinierten CircleCI-Images zu wegzugehen, wenn Du zu GitHub Actions migrierst. In vielen Fällen kannst Du die zusätzlich benötigten Abhängigkeiten mithilfe von Aktionen installieren.

Weitere Informationen über das Docker-Dateisystem findest Du unter „Virtuelle Umgebungen für GitHub Enterprise Server-gehostete Runner“. For more information about the tools and packages available on

GitHub-hosted virtual environments, see "Specifications for GitHub-hosted runners".

Variablen und Geheimnisse verwenden

CircleCI und GitHub Actions unterstützen das Setzen von Umgebungsvariablen in der Konfigurationsdatei und das Erstellen von Geheimnissen mit der Benutzeroberfläche von entweder CircleCI oder GitHub Enterprise Server.

Weitere Informationen findest Du unter „Umgebungsvariablen verwenden“ und „Verschlüsselte Geheimnisse erstellen und verwenden“.

Im Cache zwischenspeichern

CircleCI und GitHub Actions bieten in der Konfigurationsdatei eine Methode an, um Dateien manuell im Cache zwischenzuspeichern.

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

CircleCI GitHub Actions
- restore_cache:
    keys:
      - v1-npm-deps-{{ checksum "package-lock.json" }}
      - v1-npm-deps-
- name: Cache node modules
  uses: actions/cache@v2
  with:
    path: ~/.npm
    key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
    restore-keys: v1-npm-deps-

GitHub Actions caching is only applicable for repositories hosted on GitHub.com. Weitere Informationen findest Du unter „Abhängigkeiten zur Beschleunigung von Workflows im Cache zwischenspeichern“.

GitHub Actions hat kein Äquivalent zum „Docker Layer Caching“ („DLC“, im Cache auf Docker-Ebene zwischenspeichern).

Daten zwischen Jobs persistieren

Sowohl CircleCI als auch GitHub Actions bieten Mechanismen für die Persistierung von Daten zwischen Jobs.

Nachfolgend siehst Du ein Beispiel in der Konfigurationssyntax von CircleCI und GitHub Actions.

CircleCI GitHub Actions
- persist_to_workspace:
    root: workspace
    paths:
      - math-homework.txt

...

- attach_workspace:
    at: /tmp/workspace
- name: Upload math result for job 1
  uses: actions/upload-artifact@v2
  with:
    name: homework
    path: math-homework.txt

...

- name: Download math result for job 1
  uses: actions/download-artifact@v2
  with:
    name: homework

Weitere Informationen findest Du unter „Workflow-Daten mittels Artefakten persistieren“.

Datenbanken und Service-Container verwenden

Mit beiden Systemen kannst Du zusätzliche Container für Datenbanken, Zwischenspeicherung im Cache oder andere Abhängigkeiten einbinden.

In CircleCI ist das erste in der config.yaml aufgelistete Image, das primäre Image, welches benutzt wird, um Befehle auszuführen. GitHub Actions verwendet explizite Abschnitte: container für den primären Container und zusätzliche Container aufgelistet in services.

Nachfolgend siehst Du ein Beispiel in der Konfigurationssyntax von CircleCI und GitHub Actions.

CircleCI GitHub Actions
---
version: 2.1

jobs:

  ruby-26:
    docker:
      - image: circleci/ruby:2.6.3-node-browsers-legacy
        environment:
          PGHOST: localhost
          PGUSER: administrate
          RAILS_ENV: test
      - image: postgres:10.1-alpine
        environment:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby26
          POSTGRES_PASSWORD: ""

    working_directory: ~/administrate

    steps:
      - checkout

      # Abhaengigkeiten gebuendelt installieren
      - run: bundle install --path vendor/bundle

      # auf DB warten
      - run: dockerize -wait tcp://localhost:5432 -timeout 1m

      # Umgebung einrichten
      - run: cp .sample.env .env

      # Datenbank einrichten
      - run: bundle exec rake db:setup

      # Tests durchfuehren
      - run: bundle exec rake

workflows:
  version: 2
  build:
    jobs:
      - ruby-26
...

- attach_workspace:
    at: /tmp/workspace
name: Containers

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest
    container: circleci/ruby:2.6.3-node-browsers-legacy

    env:
      PGHOST: postgres
      PGUSER: administrate
      RAILS_ENV: test

    services:
      postgres:
        image: postgres:10.1-alpine
        env:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby25
          POSTGRES_PASSWORD: ""
        ports:
          - 5432:5432
        # Add a health check
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      # 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.
      # See https://docs.github.com/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
      - name: Setup file system permissions
        run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: bundle install --path vendor/bundle
      - name: Setup environment configuration
        run: cp .sample.env .env
      - name: Setup database
        run: bundle exec rake db:setup
      - name: Run tests
        run: bundle exec rake

Weitere Informationen findest Du unter „Informationen zu Servicecontainern“.

Vollständiges Beispiel

Nachfolgend siehst Du ein Beispiel aus der realen Welt. Die linke Seite zeigt die tatsächliche config.yml unter CircleCI für das Repository thoughtbot/administrator. Die rechte Seite zeigt das Äquivalent unter GitHub Actions.

CircleCI GitHub Actions
---
version: 2.1

commands:
  shared_steps:
    steps:
      - checkout

      # Abhaengigkeiten aus dem Cache wiederherstellen
      - restore_cache:
          name: Restore bundle cache
          key: administrate-{{ checksum "Gemfile.lock" }}

      # Abhaengigkeiten gebuendelt installieren
      - run: bundle install --path vendor/bundle

      # Abhaengigkeiten im Cache zwischenspeichern
      - save_cache:
          name: Store bundle cache
          key: administrate-{{ checksum "Gemfile.lock" }}
          paths:
            - vendor/bundle

      # auf DB warten
      - run: dockerize -wait tcp://localhost:5432 -timeout 1m

      # Umgebung einrichten
      - run: cp .sample.env .env

      # Datenbank einrichten
      - run: bundle exec rake db:setup

      # Tests durchfuehren
      - run: bundle exec rake

default_job: &default_job
  working_directory: ~/administrate
  steps:
    - shared_steps
    # Test mit verschiedenen Versionen von Rails durchfuehren
    - run: bundle exec appraisal install
    - run: bundle exec appraisal rake

jobs:
  ruby-25:
    <<: *default_job
    docker:
      - image: circleci/ruby:2.5.0-node-browsers
        environment:
          PGHOST: localhost
          PGUSER: administrate
          RAILS_ENV: test
      - image: postgres:10.1-alpine
        environment:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby25
          POSTGRES_PASSWORD: ""

  ruby-26:
    <<: *default_job
    docker:
      - image: circleci/ruby:2.6.3-node-browsers-legacy
        environment:
          PGHOST: localhost
          PGUSER: administrate
          RAILS_ENV: test
      - image: postgres:10.1-alpine
        environment:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby26
          POSTGRES_PASSWORD: ""

workflows:
  version: 2
  multiple-rubies:
    jobs:
      - ruby-26
      - ruby-25
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# dokumentation.

name: Containers

on: [push]

jobs:
  build:

    strategy:
      matrix:
        ruby: [2.5, 2.6.3]

    runs-on: ubuntu-latest

    env:
      PGHOST: localhost
      PGUSER: administrate
      RAILS_ENV: test

    services:
      postgres:
        image: postgres:10.1-alpine
        env:
          POSTGRES_USER: administrate
          POSTGRES_DB: ruby25
          POSTGRES_PASSWORD: ""
        ports:
          - 5432:5432
        # Add a health check
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      - uses: actions/checkout@v2
      - name: Setup Ruby
        uses: eregon/use-ruby-action@477b21f02be01bcb8030d50f37cfec92bfa615b6
        with:
          ruby-version: ${{ matrix.ruby }}
      - name: Cache dependencies
        uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
      - name: Install postgres headers
        run: |
          sudo apt-get update
          sudo apt-get install libpq-dev
      - name: Install dependencies
        run: bundle install --path vendor/bundle
      - name: Setup environment configuration
        run: cp .sample.env .env
      - name: Setup database
        run: bundle exec rake db:setup
      - name: Run tests
        run: bundle exec rake
      - name: Install appraisal
        run: bundle exec appraisal install
      - name: Run appraisal
        run: bundle exec appraisal rake