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 finden Sie unter
Verwenden eines Ruby-Starterworkflows
Für einen schnellen Einstieg füge einen Starterworkflow zum Verzeichnis .github/workflows
deines Repositorys hinzu.
GitHub bietet einen Starterworkflow für Ruby, der für die meisten Ruby-Projekte funktionieren sollte. In den nachfolgenden Abschnitten dieser Anleitung finden Sie Beispiele dafür, wie dieser Starterworkflow angepasst werden kann.
-
Navigiere auf Ihre GitHub Enterprise Server-Instance zur Hauptseite des Repositorys.
-
Klicke unter dem Namen deines Repositorys auf Aktionen.
-
Wenn du bereits über einen Workflow im Repository verfügst, klicke auf Neuer Workflow.
-
Die Seite „Workflow auswählen“ zeigt eine Auswahl empfohlener Startworkflows. Suchen Sie nach „Ruby“.
-
Filtern Sie die Auswahl von Workflows, indem Sie auf Continuous Integration klicken.
-
Klicken Sie im Workflow „Ruby“ auf Konfigurieren.
Wenn Sie den Starterworkflow „Ruby“ nicht finden, kopieren Sie den folgenden Workflowcode in eine neue Datei namens
ruby.yml
im.github/workflows
-Verzeichnis Ihres Repositorys.YAML name: Ruby on: push: branches: [ "main" ] pull_request: branches: [ "main" ] permissions: contents: read jobs: test: runs-on: ubuntu-latest strategy: matrix: ruby-version: ['2.6', '2.7', '3.0'] steps: - uses: actions/checkout@v4 - name: Set up Ruby # To automatically get bug fixes and new Ruby versions for ruby/setup-ruby, # change this to (see https://github.com/ruby/setup-ruby#versioning): # uses: ruby/setup-ruby@v1 uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0 with: ruby-version: ${{ matrix.ruby-version }} bundler-cache: true # runs 'bundle install' and caches installed gems automatically - name: Run tests run: bundle exec rake
name: Ruby on: push: branches: [ "main" ] pull_request: branches: [ "main" ] permissions: contents: read jobs: test: runs-on: ubuntu-latest strategy: matrix: ruby-version: ['2.6', '2.7', '3.0'] steps: - uses: actions/checkout@v4 - name: Set up Ruby # To automatically get bug fixes and new Ruby versions for ruby/setup-ruby, # change this to (see https://github.com/ruby/setup-ruby#versioning): # uses: ruby/setup-ruby@v1 uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0 with: ruby-version: ${{ matrix.ruby-version }} bundler-cache: true # runs 'bundle install' and caches installed gems automatically - name: Run tests run: bundle exec rake
-
Bearbeiten Sie den Workflow nach Bedarf. Ändern Sie beispielsweise die Ruby-Versionen, die Sie verwenden möchten.
Hinweise:
- Dieser Starterworkflow enthält eine Aktion, die nicht von GitHub zertifiziert wurde. Aktionen, die von einem Drittanbieter bereitgestellt werden unterliegen separaten Nutzungsbedingungen, Datenschutzrichtlinien und Supportdokumentationen.
- Wenn du Aktionen von Drittanbietern verwendest, solltest du eine Version verwenden, die durch einen Commit-SHA angegeben ist. Wenn die Aktion überarbeitet wird und du die neuere Version verwenden möchtest, musst du den SHA aktualisieren. Du kannst eine Version auch angeben, indem du auf ein Tag oder einen Branch verweist, aber die Aktion kann sich ohne Vorwarnung ändern. Weitere Informationen findest du unter Sicherheitshärtung für GitHub Actions.
-
Klicke auf Änderungen committen.
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@v4
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
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@v4
- name: Set up Ruby ${{ matrix.ruby-version }}
uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
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@v4
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
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@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
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 Abhängigkeiten zwischenspeichern um Workflows zu beschleunigen.
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@v4
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
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@v4
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
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@v4
- name: Set up Ruby 2.6
uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
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}}"