Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.
Introduction
Ce guide explique comment créer un workflow d’intégration continue (CI) qui génère et teste une application Ruby. Si vos tests CI réussissent, vous pouvez déployer votre code ou publier un gem.
Prérequis
Il est recommandé d’avoir une compréhension de base de Ruby, du YAML, des options de configuration de workflows et de la création de fichiers de workflow. Pour plus d'informations, consultez les pages suivantes :
Utilisation d’un modèle de workflow Ruby
Pour démarrer rapidement, ajoutez un modèle de workflow au répertoire .github/workflows
de votre référentiel.
GitHub fournit un modèle de workflow pour Ruby qui devrait fonctionner pour la plupart des projets Ruby. Les sections suivantes de ce guide donnent des exemples de la manière dont vous pouvez personnaliser ce modèle de workflow.
-
Sur GitHub, accédez à la page principale du référentiel.
-
Sous le nom de votre dépôt, cliquez sur Actions.
-
Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur Nouveau workflow.
-
La page « Choisir un workflow » présente une sélection de modèles de workflow recommandés. Recherchez « ruby ».
-
Filtrez la sélection des flux de travail en cliquant sur Intégration continue.
-
Dans le flux de travail « Ruby », cliquez sur Configurer.
Si vous ne trouvez pas le modèle de workflow « Ruby », copiez le code de workflow suivant dans un nouveau fichier appelé
ruby.yml
dans le répertoire.github/workflows
de votre référentiel.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
-
Modifiez le workflow en fonction des besoins. Par exemple, modifiez les versions de Ruby que vous voulez utiliser.
Remarques :
- Ce modèle de workflow contient une action qui n’est pas certifiée par GitHub. Elles sont fournies par un tiers et sont régies par des conditions d’utilisation du service, une politique de confidentialité et une documentation de support distinctes.
- Si vous utilisez des actions de tiers, vous devez utiliser une version spécifiée par un commit SHA. Si l’action est révisée et que vous voulez utiliser la version la plus récente, vous devez mettre à jour le SHA. Vous pouvez spécifier une version en faisant référence à une balise ou à une branche, mais l’action peut changer sans avertissement. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».
-
Cliquez sur Valider les changements.
Spécification de la version Ruby
Le moyen le plus simple de spécifier une version Ruby consiste à utiliser l’action ruby/setup-ruby
fournie par Ruby sur GitHub. L’action ajoute toute version Ruby prise en charge à PATH
pour chaque exécution de travail d’un workflow. Pour plus d’informations et pour connaître les versions Ruby disponibles, consultez ruby/setup-ruby
.
L’action ruby/setup-ruby
de Ruby est recommandée pour utiliser Ruby avec GitHub Actions, car elle garantit un comportement cohérent entre les différents exécuteurs et les différentes versions de Ruby.
L’action setup-ruby
prend une version Ruby en tant qu’entrée et configure cette version sur l’exécuteur.
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
Vous pouvez également effectuer le check-in d’un fichier .ruby-version
à la racine de votre dépôt pour que setup-ruby
utilise la version définie dans ce fichier.
Effectuer des tests avec plusieurs versions de Ruby
Vous pouvez ajouter une stratégie de matrice pour exécuter votre workflow avec plusieurs versions de Ruby. Par exemple, vous pouvez tester votre code par rapport aux dernières versions correctives des versions 3.1, 3.0 et 2.7.
strategy:
matrix:
ruby-version: ['3.1', '3.0', '2.7']
Chaque version de Ruby spécifiée dans le tableau ruby-version
crée un travail qui exécute les mêmes étapes. Le contexte ${{ matrix.ruby-version }}
est utilisé pour accéder à la version du travail actuel. Pour plus d’informations sur les stratégies de matrice et les contextes, consultez « Workflow syntax for GitHub Actions » et « Accès à des informations contextuelles sur l’exécution d’un workflow ».
Le workflow complet mis à jour avec une stratégie de matrice peut ressembler à ceci :
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.
# GitHub recommande d’épingler les actions à un SHA de commit.
# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.
# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.
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
Installation de dépendances avec Bundler
L’action setup-ruby
installe automatiquement Bundler. La version est déterminée par votre fichier gemfile.lock
. Si aucune version n’est présente dans votre lockfile, la dernière version compatible sera installée.
steps:
- uses: actions/checkout@v4
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: '3.1'
- run: bundle install
Mise en cache des dépendances
Les actions setup-ruby
fournissent une méthode pour gérer automatiquement la mise en cache de vos gemmes entre les exécutions.
Pour activer la mise en cache, définissez les éléments suivants.
steps:
- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
bundler-cache: true
Cela configurera Bundler de manière à installer vos gems sur vendor/cache
. Pour chaque exécution réussie de votre workflow, ce dossier sera mis en cache par GitHub Actions, puis re-téléchargé pour les exécutions de workflows suivantes. Un hachage de votre gemfile.lock et la version Ruby sont utilisés comme clé de cache. Si vous installez de nouveaux gems ou modifiez une version, le cache ne sera plus valide et Bundler effectuera une nouvelle installation.
Mise en cache sans setup-ruby
Pour mieux contrôler la mise en cache, vous pouvez utiliser l’action actions/cache
directement. Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les 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
Si vous utilisez une build de matrice, vous devez inclure les variables de matrice dans votre clé de cache. Par exemple, si vous avez une stratégie de matrice pour différentes versions de Ruby (matrix.ruby-version
) et différents systèmes d’exploitation (matrix.os
), vos étapes de workflows peuvent ressembler à ceci :
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
Tester votre code avec la matrice
L’exemple de matrice suivant teste toutes les versions stables et versions principales de MRI, JRuby et TruffleRuby sur Ubuntu et macOS.
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.
# GitHub recommande d’épingler les actions à un SHA de commit.
# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.
# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.
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
Linting de votre code
L’exemple suivant installe rubocop
, et l’utilise pour effectuer le linting de tous les fichiers. Pour plus d’informations, consultez RuboCop. Vous pouvez configurer Rubocop pour décider des règles de linting.
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.
# GitHub recommande d’épingler les actions à un SHA de commit.
# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.
# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.
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 -f github
La spécification -f github
signifie que la sortie RuboCop sera dans le format d’annotation GitHub. Toutes les erreurs de linting seront affichées en ligne dans l’onglet Fichiers modifiés de la demande de traction qui les a introduites.
Publication de gems
Vous pouvez configurer votre workflow pour publier votre package Ruby dans n’importe quel registre de packages lorsque vos tests d’intégration continue réussissent.
Vous pouvez stocker tous les jetons d’accès ou informations d’identification nécessaires pour publier votre package à l’aide de secrets de dépôt. L’exemple suivant crée et publie un package sur GitHub Package Registry
et RubyGems
.
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.
# GitHub recommande d’épingler les actions à un SHA de commit.
# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.
# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.
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}}"