Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

Erstellen und Testen von Ruby-Anwendungen

Du kannst einen Continuous Integration-Workflow (CI) erstellen, um dein Ruby-Projekt zu kompilieren und zu testen.

Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

Einführung

In diesem Leitfaden erfährst du, wie du einen CI-Workflow (Continuous Integration) erstellst, mit dem eine Ruby-Anwendung erstellt und getestet wird. Wenn deine CI-Tests bestanden wurden, solltest du den Code bereitstellen oder ein Ruby-Gem veröffentlichen.

Voraussetzungen

Es wird empfohlen, grundlegende Kenntnisse über Ruby, YAML, Workflowkonfigurationsoptionen und das Erstellen einer Workflowdatei zu haben. Weitere Informationen findest du unter

Verwenden des Ruby-Starterworkflows

GitHub bietet einen Ruby-Starterworkflow, der für die meisten Ruby-Projekte funktioniert. Weitere Informationen findest du unter Ruby-Starterworkflow.

Für einen schnellen Einstieg fügst du den Starterworkflow zum Verzeichnis .github/workflows deines Repositorys hinzu. Im nachstehenden Workflow wird davon ausgegangen, dass der Standardbranch für dein Repository main lautet.

# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.

# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.
# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.
# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.

name: Ruby

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - name: Set up Ruby
        uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
        with:
          ruby-version: '3.1'
      - name: Install dependencies
        run: bundle install
      - name: Run tests
        run: bundle exec rake

Angeben der Ruby-Version

Am einfachsten kannst du eine Ruby-Version angeben, indem du die Aktion ruby/setup-ruby verwendest, die von der Ruby-Organisation auf GitHub bereitgestellt wird. Mit der Aktion wird für jeden Auftrag, der in einem Workflow ausgeführt wird, eine beliebige unterstützte Ruby-Version zu PATH hinzugefügt. Weitere Informationen und verfügbare Ruby-Versionen findest du unter ruby/setup-ruby.

Die Aktion ruby/setup-ruby von Ruby wird als Methode zur Verwendung von Ruby mit GitHub Actions empfohlen, da damit ein konsistentes Verhalten bei verschiedenen Runnern und verschiedenen Version von Ruby gewährleistet wird.

Von der Aktion setup-ruby wird eine Ruby-Version als Eingabe verwendet und auf dem Runner konfiguriert.

steps:
- uses: actions/checkout@v3
- uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
  with:
    ruby-version: '3.1' # Not needed with a .ruby-version file
- run: bundle install
- run: bundle exec rake

Alternativ dazu kannst du eine .ruby-version-Datei in das Stammverzeichnis deines Repositorys einchecken; die in dieser Datei definierte Version wird dann von setup-ruby verwendet.

Testen mit mehreren Versionen von Ruby

Du kannst eine Matrixstrategie hinzufügen, um den Workflow mit mehr als einer Version von Ruby auszuführen. Du kannst den Code beispielsweise in Bezug auf die aktuellen Patchreleases der Versionen 3.1, 3.0 und 2.7 testen.

strategy:
  matrix:
    ruby-version: ['3.1', '3.0', '2.7']

Von jeder im ruby-version-Array angegebenen Version von Ruby wird ein Auftrag erstellt, bei dem dieselben Schritte ausgeführt werden. Der ${{ matrix.ruby-version }}-Kontext wird dazu verwendet, auf die Version des aktuellen Auftrags zuzugreifen. Weitere Informationen zu Matrixstrategien und Kontexten findest du unter Workflowsyntax für GitHub Actions und Kontexte.

Der vollständige aktualisierte Workflow mit einer Matrixstrategie könnte wie folgt aussehen:

# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.

# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.
# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.
# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.

name: Ruby CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        ruby-version: ['3.1', '3.0', '2.7']

    steps:
      - uses: actions/checkout@v3
      - name: Set up Ruby ${{ matrix.ruby-version }}
        uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
        with:
          ruby-version: ${{ matrix.ruby-version }}
      - name: Install dependencies
        run: bundle install
      - name: Run tests
        run: bundle exec rake

Installieren von Abhängigkeiten mit Bundler

Mit der Aktion setup-ruby wird Bundler automatisch für dich installiert. Die Version wird von der Datei gemfile.lock bestimmt. Wenn in der Sperrdatei keine Version vorhanden ist, wird die aktuelle kompatible Version installiert.

steps:
- uses: actions/checkout@v3
- uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
  with:
    ruby-version: '3.1'
- run: bundle install

Abhängigkeiten „cachen“ (zwischenspeichern)

Die setup-ruby-Aktionen bieten eine Methode, mit der du deine Gems automatisch zwischenspeichern kannst.

Lege zum Aktivieren der Zwischenspeicherung Folgendes fest.

steps:
- uses: ruby/setup-ruby@359bebbc29cbe6c87da6bc9ea3bc930432750108
    with:
      bundler-cache: true

Dadurch wird der Bundler so konfiguriert, dass deine Gems in vendor/cache installiert werden. Bei jeder erfolgreichen Ausführung deines Workflows wird dieser Ordner von GitHub Actions zwischengespeichert und bei nachfolgenden Workflowausführungen erneut heruntergeladen. Ein Hash deiner gemfile.lock-Datei und die Ruby-Version werden als Cacheschlüssel verwendet. Wenn du neue Gems installierst oder eine Version änderst, wird der Cache ungültig, und von Bundler wird eine neue Installation durchgeführt.

Zwischenspeichern ohne setup-ruby-Aktion

Um die Zwischenspeicherung besser zu steuern, kannst du die actions/cache-Aktion direkt verwenden. Weitere Informationen findest du unter Zwischenspeichern von Abhängigkeiten zum Beschleunigen von Workflows.

steps:
- uses: actions/cache@v3
  with:
    path: vendor/bundle
    key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
    restore-keys: |
      ${{ runner.os }}-gems-
- name: Bundle install
  run: |
    bundle config path vendor/bundle
    bundle install --jobs 4 --retry 3

Wenn du einen Matrixbuild verwendest, solltest du die Matrixvariablen in den Cacheschlüssel aufnehmen. Wenn du beispielsweise eine Matrixstrategie für verschiedene Ruby-Versionen (matrix.ruby-version) und unterschiedliche Betriebssysteme (matrix.os) hast, sehen die Workflowschritte möglicherweise wie folgt aus:

steps:
- uses: actions/cache@v3
  with:
    path: vendor/bundle
    key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}
    restore-keys: |
      bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-
- name: Bundle install
  run: |
    bundle config path vendor/bundle
    bundle install --jobs 4 --retry 3

Matrixtests des Codes

Mit der folgenden Beispielmatrix werden alle stabilen Releases und Headversionen von MRI, JRuby und TruffleRuby unter Ubuntu und macOS getestet.

# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.

# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.
# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.
# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.

name: Matrix Testing

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ${{ matrix.os }}-latest
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu, macos]
        ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]
    continue-on-error: ${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}
    steps:
      - uses: actions/checkout@v3
      - uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
        with:
          ruby-version: ${{ matrix.ruby }}
      - run: bundle install
      - run: bundle exec rake

Linten des Codes

Im folgenden Beispiel wird rubocop installiert und zum Linten aller Dateien verwendet. Weitere Informationen findest du unter RuboCop. Du kannst Rubocop so konfigurieren, dass jeweils spezifische Regeln für das Linten festlegen.

# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.

# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.
# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.
# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.

name: Linting

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
        with:
          ruby-version: 2.6
      - run: bundle install
      - name: Rubocop
        run: rubocop

Veröffentlichen von Gems

Du kannst deinen Workflow so konfigurieren, dass das Ruby-Paket in jeder Paketregistrierung veröffentlicht wird, die du wünschst, wenn deine CI-Tests bestanden werden.

Du kannst alle Zugriffstoken oder Anmeldeinformationen speichern, die zum Veröffentlichen deines Pakets mithilfe von geheimen Repositoryschlüsseln erforderlich sind. Im folgenden Beispiel wird ein Paket erstellt und in GitHub Package Registry und RubyGems veröffentlicht.

# Dieser Workflow verwendet Aktionen, die nicht von GitHub zertifiziert sind.
# Sie werden von einem Drittanbieter bereitgestellt und unterliegen
# separaten Nutzungsbedingungen, Datenschutzbestimmungen und Support
# Onlinedokumentation.

# GitHub empfiehlt, Aktionen an einen Commit-SHA anzuheften.
# Um eine neuere Version zu erhalten, musst du den SHA aktualisieren.
# Du kannst auch auf ein Tag oder einen Branch verweisen, aber die Aktion kann sich ohne Vorwarnung ändern.

name: Ruby Gem

on:
  # Manually publish
  workflow_dispatch:
  # Alternatively, publish whenever changes are merged to the `main` branch.
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    name: Build + Publish
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

    steps:
      - uses: actions/checkout@v3
      - name: Set up Ruby 2.6
        uses: ruby/setup-ruby@477b21f02be01bcb8030d50f37cfec92bfa615b6
        with:
          ruby-version: 2.6
      - run: bundle install

      - name: Publish to GPR
        run: |
          mkdir -p $HOME/.gem
          touch $HOME/.gem/credentials
          chmod 0600 $HOME/.gem/credentials
          printf -- "---\n:github: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
          gem build *.gemspec
          gem push --KEY github --host https://rubygems.pkg.github.com/${OWNER} *.gem
        env:
          GEM_HOST_API_KEY: "Bearer ${{secrets.GITHUB_TOKEN}}"
          OWNER: ${{ github.repository_owner }}

      - name: Publish to RubyGems
        run: |
          mkdir -p $HOME/.gem
          touch $HOME/.gem/credentials
          chmod 0600 $HOME/.gem/credentials
          printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
          gem build *.gemspec
          gem push *.gem
        env:
          GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"