{"meta":{"title":"Erstellen und Testen von Ruby-Anwendungen","intro":"Du kannst einen Continuous Integration-Workflow (CI) erstellen, um dein Ruby-Projekt zu kompilieren und zu testen.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/de/enterprise-cloud@latest/actions/tutorials","title":"Anleitungen"},{"href":"/de/enterprise-cloud@latest/actions/tutorials/build-and-test-code","title":"Erstellen und Testen von Code"},{"href":"/de/enterprise-cloud@latest/actions/tutorials/build-and-test-code/ruby","title":"Ruby"}],"documentType":"article"},"body":"# Erstellen und Testen von Ruby-Anwendungen\n\nDu kannst einen Continuous Integration-Workflow (CI) erstellen, um dein Ruby-Projekt zu kompilieren und zu testen.\n\n## Einleitung\n\nIn 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.\n\n## Voraussetzungen\n\nEs wird empfohlen, grundlegende Kenntnisse über Ruby, YAML, Workflowkonfigurationsoptionen und das Erstellen einer Workflowdatei zu haben. Weitere Informationen finden Sie unter\n\n* [Informationen zu GitHub Actions](/de/enterprise-cloud@latest/actions/learn-github-actions)\n* [Ruby in 20 Minuten](https://www.ruby-lang.org/en/documentation/quickstart/)\n\n## Verwenden einer Ruby-Workflowvorlage\n\nFügen Sie für einen schnellen Einstieg dem Verzeichnis `.github/workflows` Ihres Repositorys eine Workflowvorlage hinzu.\n\nGitHub stellt eine Workflowvorlage für Ruby bereit, die für die meisten Ruby-Projekte funktioniert. In den folgenden Abschnitten dieser Anleitung finden Sie Beispiele dafür, wie diese Workflowvorlage angepasst werden kann.\n\n1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.\n\n2. Klicke unter dem Repositorynamen auf ** Actions**.\n\n ![Screenshot: Registerkarten für das Repository „github/docs“. Die Registerkarte „Aktionen“ ist mit einem orangefarbenen Rahmen hervorgehoben.](/assets/images/help/repository/actions-tab-global-nav-update.png)\n\n3. Wenn du bereits über einen Workflow im Repository verfügst, klicke auf **Neuer Workflow**.\n\n4. Auf der Seite „Workflow auswählen“ wird eine Auswahl empfohlener Workflowvorlagen angezeigt. Suchen Sie nach „Ruby“.\n\n5. Filtern Sie die Auswahl von Workflows, indem Sie auf **Continuous Integration** klicken.\n\n6. Klicken Sie im Workflow „Ruby“ auf **Konfigurieren**.\n\n7. Bearbeiten Sie den Workflow nach Bedarf. Ändern Sie beispielsweise die Ruby-Versionen, die Sie verwenden möchten.\n\n > \\[!NOTE]\n >\n > * Diese Workflowvorlage enthält eine Aktion, die nicht von GitHub zertifiziert wurde. Aktionen, die von einem Drittanbieter bereitgestellt werden unterliegen separaten Nutzungsbedingungen, Datenschutzrichtlinien und Supportdokumentationen.\n > * 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 finden Sie unter [Referenz zur sicheren Verwendung](/de/enterprise-cloud@latest/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions).\n\n8. Klicke auf **Änderungen committen**.\n\nDie `ruby.yml`-Workflowdatei wird dem `.github/workflows`-Verzeichnis Ihres Repositorys hinzugefügt.\n\n## Angeben der Ruby-Version\n\nDie einfachste Möglichkeit zum Angeben einer Ruby-Version ist die Verwendung der `ruby/setup-ruby`-Aktion, 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 finden Sie unter [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby).\n\nDie Verwendung der `ruby/setup-ruby`-Aktion von Ruby ist die empfohlene Methode zur Verwendung von Ruby mit GitHub Actions, da es ein konsistentes Verhalten für läuferübergreifende und unterschiedliche Versionen von Ruby gewährleistet.\n\nVon der Aktion `setup-ruby` wird eine Ruby-Version als Eingabe verwendet und auf dem Runner konfiguriert.\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.\nsteps:\n- uses: actions/checkout@v6\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '3.1' # Not needed with a .ruby-version file\n- run: bundle install\n- run: bundle exec rake\n```\n\nAlternativ können Sie eine `.ruby-version`-Datei in das Stammverzeichnis Ihres Repositorys einchecken. `setup-ruby` verwendet anschließend die in dieser Datei definierte Version.\n\n## Testen mit mehreren Versionen von Ruby\n\nDu 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.\n\n```yaml\nstrategy:\n matrix:\n ruby-version: ['3.1', '3.0', '2.7']\n```\n\nVon 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 finden Sie unter [Workflowsyntax für GitHub Actions](/de/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions) und [Kontextreferenz](/de/enterprise-cloud@latest/actions/learn-github-actions/contexts).\n\nDer vollständige aktualisierte Workflow mit einer Matrixstrategie könnte wie folgt aussehen:\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: Ruby CI\n\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\njobs:\n test:\n\n runs-on: ubuntu-latest\n\n strategy:\n matrix:\n ruby-version: ['3.1', '3.0', '2.7']\n\n steps:\n - uses: actions/checkout@v6\n - name: Set up Ruby ${{ matrix.ruby-version }}\n uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: ${{ matrix.ruby-version }}\n - name: Install dependencies\n run: bundle install\n - name: Run tests\n run: bundle exec rake\n```\n\n## Installieren von Abhängigkeiten mit Bundler\n\nMit 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.\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.\nsteps:\n- uses: actions/checkout@v6\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '3.1'\n- run: bundle install\n```\n\n### Abhängigkeiten „cachen“ (zwischenspeichern)\n\nDie `setup-ruby`-Aktionen bieten eine Methode, mit der du deine Gems automatisch zwischenspeichern kannst.\n\nLege zum Aktivieren der Zwischenspeicherung Folgendes fest.\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.\nsteps:\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n bundler-cache: true\n```\n\nDadurch 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 von `gemfile.lock` 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.\n\n```\n **Zwischenspeichern ohne setup-ruby-Aktion**\n```\n\nUm die Zwischenspeicherung besser zu steuern, kannst du die `actions/cache`-Aktion direkt verwenden. Weitere Informationen finden Sie unter [Referenz zum Zwischenspeichern von Abhängigkeiten](/de/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\n\n```yaml\nsteps:\n- uses: actions/cache@v4\n with:\n path: vendor/bundle\n key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}\n restore-keys: |\n ${{ runner.os }}-gems-\n- name: Bundle install\n run: |\n bundle config path vendor/bundle\n bundle install --jobs 4 --retry 3\n```\n\nWenn 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:\n\n```yaml\nsteps:\n- uses: actions/cache@v4\n with:\n path: vendor/bundle\n key: bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-${{ hashFiles('**/Gemfile.lock') }}\n restore-keys: |\n bundle-use-ruby-${{ matrix.os }}-${{ matrix.ruby-version }}-\n- name: Bundle install\n run: |\n bundle config path vendor/bundle\n bundle install --jobs 4 --retry 3\n```\n\n## Matrixtests des Codes\n\nMit der folgenden Beispielmatrix werden alle stabilen Releases und Headversionen von MRI, JRuby und TruffleRuby unter Ubuntu und macOS getestet.\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: Matrix Testing\n\non:\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\njobs:\n test:\n runs-on: ${{ matrix.os }}-latest\n strategy:\n fail-fast: false\n matrix:\n os: [ubuntu, macos]\n ruby: [2.5, 2.6, 2.7, head, debug, jruby, jruby-head, truffleruby, truffleruby-head]\n continue-on-error: ${{ endsWith(matrix.ruby, 'head') || matrix.ruby == 'debug' }}\n steps:\n - uses: actions/checkout@v6\n - uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: ${{ matrix.ruby }}\n - run: bundle install\n - run: bundle exec rake\n```\n\n## Linten des Codes\n\nIm folgenden Beispiel wird `rubocop` installiert und zum Linten aller Dateien verwendet. Weitere Informationen findest du unter [RuboCop](https://github.com/rubocop-hq/rubocop). Du kannst [Rubocop so konfigurieren](https://docs.rubocop.org/rubocop/configuration.html), dass jeweils spezifische Regeln für das Linten festlegen.\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: Linting\n\non: [push]\n\njobs:\n test:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '2.6'\n - run: bundle install\n - name: Rubocop\n run: rubocop -f github\n```\n\n```\n `-f github` festzulegen, bedeutet, dass sich die RuboCop-Ausgabe im Anmerkungsformat von GitHub befindet. Alle Lintingfehler werden inline auf der Registerkarte **Geänderte Dateien** des Pull Requests angezeigt, der sie einführt.\n```\n\n## Veröffentlichen von Gems\n\nDu 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.\n\nDu 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 für `GitHub Package Registry` und `RubyGems` erstellt und veröffentlicht.\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: Ruby Gem\n\non:\n # Manually publish\n workflow_dispatch:\n # Alternatively, publish whenever changes are merged to the `main` branch.\n push:\n branches: [ main ]\n pull_request:\n branches: [ main ]\n\njobs:\n build:\n name: Build + Publish\n runs-on: ubuntu-latest\n permissions:\n packages: write\n contents: read\n\n steps:\n - uses: actions/checkout@v6\n - name: Set up Ruby 2.6\n uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n ruby-version: '2.6'\n - run: bundle install\n\n - name: Publish to GPR\n run: |\n mkdir -p $HOME/.gem\n touch $HOME/.gem/credentials\n chmod 0600 $HOME/.gem/credentials\n printf -- \"---\\n:github: ${GEM_HOST_API_KEY}\\n\" > $HOME/.gem/credentials\n gem build *.gemspec\n gem push --KEY github --host https://rubygems.pkg.github.com/${OWNER} *.gem\n env:\n GEM_HOST_API_KEY: \"Bearer ${{secrets.GITHUB_TOKEN}}\"\n OWNER: ${{ github.repository_owner }}\n\n - name: Publish to RubyGems\n run: |\n mkdir -p $HOME/.gem\n touch $HOME/.gem/credentials\n chmod 0600 $HOME/.gem/credentials\n printf -- \"---\\n:rubygems_api_key: ${GEM_HOST_API_KEY}\\n\" > $HOME/.gem/credentials\n gem build *.gemspec\n gem push *.gem\n env:\n GEM_HOST_API_KEY: \"${{secrets.RUBYGEMS_AUTH_TOKEN}}\"\n```"}