{"meta":{"title":"Création et test de code Ruby","intro":"Vous pouvez créer un workflow d’intégration continue (CI) pour générer et tester votre projet Ruby.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/enterprise-server@3.14/actions","title":"GitHub Actions"},{"href":"/fr/enterprise-server@3.14/actions/tutorials","title":"Tutoriels"},{"href":"/fr/enterprise-server@3.14/actions/tutorials/build-and-test-code","title":"Générer et tester du code"},{"href":"/fr/enterprise-server@3.14/actions/tutorials/build-and-test-code/ruby","title":"Ruby"}],"documentType":"article"},"body":"# Création et test de code Ruby\n\nVous pouvez créer un workflow d’intégration continue (CI) pour générer et tester votre projet Ruby.\n\n> \\[!NOTE]\n> Les exécuteurs hébergés sur GitHub Enterprise Server ne sont pas pris en charge sur GitHub.\n\n## Présentation\n\nCe 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.\n\n## Prérequis\n\nIl 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 :\n\n* [Découvrir GitHub Actions](/fr/enterprise-server@3.14/actions/learn-github-actions)\n* [Ruby en 20 minutes](https://www.ruby-lang.org/en/documentation/quickstart/)\n\n## Utilisation d’un modèle de workflow Ruby\n\nPour démarrer rapidement, ajoutez un modèle de workflow au répertoire `.github/workflows` de votre référentiel.\n\nGitHub fournit un modèle de workflow pour Ruby qui fonctionne 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.\n\n1. Sur GitHub, accédez à la page principale du référentiel.\n\n2. Sous le nom de votre référentiel, cliquez sur ** Actions**.\n\n ![Capture d’écran des onglets du référentiel « github/docs ». L’onglet « Actions » est mis en surbrillance avec un encadré orange.](/assets/images/help/repository/actions-tab-global-nav-update.png)\n\n3. Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur **Nouveau workflow**.\n\n4. La page « Choisir un workflow » présente une sélection de modèles de workflow recommandés. Recherchez « Ruby ».\n\n5. Filtrez la sélection de workflows en cliquant sur **Intégration continue**.\n\n6. Sur le workflow « Ruby », cliquez sur **Configurer**.\n\n 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 dépôt.\n\n ```yaml copy\n # Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n # Elles sont fournies par un tiers et régies par\n # des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n # documentation en ligne.\n name: Ruby\n\n on:\n push:\n branches: [ \"main\" ]\n pull_request:\n branches: [ \"main\" ]\n\n permissions:\n contents: read\n\n jobs:\n test:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n ruby-version: ['2.6', '2.7', '3.0']\n\n steps:\n - uses: actions/checkout@v6\n - name: Set up Ruby\n # To automatically get bug fixes and new Ruby versions for ruby/setup-ruby,\n # change this to (see https://github.com/ruby/setup-ruby#versioning):\n # uses: ruby/setup-ruby@v1\n uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0\n with:\n ruby-version: ${{ matrix.ruby-version }}\n bundler-cache: true # runs 'bundle install' and caches installed gems automatically\n - name: Run tests\n run: bundle exec rake\n ```\n\n7. Modifiez le workflow en fonction des besoins. Par exemple, modifiez les versions de Ruby que vous voulez utiliser.\n\n > \\[!NOTE]\n >\n > * 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.\n > * 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 « [Informations de référence sur l’utilisation sécurisée](/fr/enterprise-server@3.14/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions) ».\n\n8. Cliquez sur **Commiter les changements**.\n\n## Spécification de la version Ruby\n\nLe moyen le plus simple de spécifier une version ruby consiste à utiliser l’action `ruby/setup-ruby` fournie par l’organisation 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 de Ruby disponibles, consultez [`ruby/setup-ruby`](https://github.com/ruby/setup-ruby).\n\nL'utilisation de l'action `ruby/setup-ruby` de Ruby est la méthode recommandée d'utiliser Ruby avec GitHub Actions, car elle garantit un comportement cohérent entre différents exécuteurs et différentes versions de Ruby.\n\nL’action `setup-ruby` prend une version Ruby en tant qu’entrée et configure cette version sur l’exécuteur.\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\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\nVous pouvez également ajouter un fichier `.ruby-version` à la racine de votre dépôt pour que `setup-ruby` utilise la version définie dans ce fichier.\n\n## Effectuer des tests avec plusieurs versions de Ruby\n\nVous 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.\n\n```yaml\nstrategy:\n matrix:\n ruby-version: ['3.1', '3.0', '2.7']\n```\n\nChaque 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 [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.14/actions/using-workflows/workflow-syntax-for-github-actions) et [Référence des contextes](/fr/enterprise-server@3.14/actions/learn-github-actions/contexts).\n\nLe workflow complet mis à jour avec une stratégie de matrice peut ressembler à ceci :\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\n\n# GitHub recommande d’épingler les actions à un SHA de commit.\n# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.\n# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.\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## Installation de dépendances avec Bundler\n\nL’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.\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\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### Mise en cache des dépendances\n\nLes actions `setup-ruby` fournissent une méthode pour gérer automatiquement la mise en cache de vos gemmes entre les exécutions.\n\nPour activer la mise en cache, définissez les éléments suivants.\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\nsteps:\n- uses: ruby/setup-ruby@ec02537da5712d66d4d50a0f33b7eb52773b5ed1\n with:\n bundler-cache: true\n```\n\nCela 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 de la version de Ruby est utilisé 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.\n\n```\n **Mise en cache sans setup-ruby**\n```\n\nPour mieux contrôler la mise en cache, vous pouvez utiliser l’action `actions/cache` directement. Pour plus d’informations, consultez « [Référence sur la mise en cache des dépendances](/fr/enterprise-server@3.14/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\nSi 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 :\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## Tester votre code avec la matrice\n\nL’exemple de matrice suivant teste toutes les versions stables et versions principales de MRI, JRuby et TruffleRuby sur Ubuntu et macOS.\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\n\n# GitHub recommande d’épingler les actions à un SHA de commit.\n# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.\n# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.\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## Linting de votre code\n\nL’exemple suivant installe `rubocop`, et l’utilise pour effectuer le linting de tous les fichiers. Pour plus d’informations, consultez [RuboCop](https://github.com/rubocop-hq/rubocop). Vous pouvez [configurer Rubocop](https://docs.rubocop.org/rubocop/configuration.html) pour décider des règles de linting.\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\n\n# GitHub recommande d’épingler les actions à un SHA de commit.\n# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.\n# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.\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\nLa spécification de `-f github` signifie que la sortie RuboCop sera au format d’annotation de GitHub. Toute erreur de linting sera intégrée dans l’onglet **Fichiers modifiés** de la demande de tirage qui l’a introduite.\n\n## Publication de gems\n\nVous 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.\n\nVous 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`.\n\n```yaml\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\n\n# GitHub recommande d’épingler les actions à un SHA de commit.\n# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.\n# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.\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```"}