Skip to main content
Présenté par Collin pour GoRails. Republié sur AppSignal le 19 septembre 2026. Rails 8.1 est livré avec un CI local. bin/ci exécute vos vérifications sur votre propre machine, piloté par un script situé dans config/ci.rb que les nouvelles applications génèrent pour vous. L’argument en sa faveur est simple. Un exécuteur hébergé est souvent plus lent que l’ordinateur portable déjà devant vous, et pour de nombreux projets, l’attente est la seule chose qu’il ajoute. Ce travail a été mené par Jeremy Daer chez 37signals.

​
Ce que ce tutoriel couvre

  • Lire et étendre config/ci.rb.
  • Exécuter la suite avec bin/ci.
  • Signaler une réussite locale sur une pull request GitHub.

​
Prérequis

​
Le script CI

config/ci.rb liste les étapes à exécuter. La version générée appelle des scripts déjà présents dans bin :
  • bin/setup prépare l’environnement.
  • bin/rubocop exécute les vérifications de style.
  • Bundler Audit vérifie les gems à la recherche de vulnérabilités connues.
  • Importmap Audit fait de même pour JavaScript.
  • La suite de tests s’exécute.
Rien n’est caché ici. Chaque étape est un script ordinaire dans bin, lisible et exécutable seul, ce qui rend un échec facile à reproduire isolément. Ajoutez des étapes pour tout ce dont votre projet a besoin, et supprimez celles qui ne s’appliquent pas.

​
Exécuter

La sortie affiche une ligne par étape, avec un total à la fin. Un échec indique le nom de l’étape qui a échoué, vous la corrigez et relancez. Une réussite complète sur une petite application prend quelques dizaines de secondes.

​
Valider une pull request

Exécuter le CI en local ne laisse aucune trace sur GitHub indiquant qu’il a réussi. L’intégration de validation en ajoute une : elle publie un status check sur la branche indiquant que les vérifications se sont exécutées et ont réussi. Installez la GitHub CLI, puis l’extension :
Activez ensuite le bloc de validation dans config/ci.rb. Lors d’une exécution réussie, il valide le commit et le check apparaît sur la pull request. Lors d’une exécution en échec, il ne le fait pas. Deux choses posent problème la première fois, et les deux produisent le même message « sign-off failed » : Les deux suivent la même règle : la validation atteste d’un commit qui existe sur le remote. Commitez, poussez, puis exécutez bin/ci.

​
Ce que cela change pour votre monitoring

Déplacer le CI sur les machines des développeurs supprime un point de contrôle qui était aussi, au passage, une trace. Le CI hébergé enregistre chaque exécution en regard d’un commit ; un exécuteur local ne le fait pas, à l’exception du check de validation. Cela justifie d’être délibéré sur la trace que vous conservez après le déploiement :
  • Envoyez un marqueur de déploiement à chaque déploiement. Les marqueurs placent une ligne sur vos graphiques au moment où une révision est publiée, et regroupent les erreurs par déploiement qui les a introduites. Avec un CI local, le marqueur est souvent la première trace durable qui relie une révision à un moment précis.
  • Surveillez le déploiement plutôt que le build. Une exécution locale au vert et un serveur de build au vert vous disent la même chose : vos vérifications ont réussi sur le code que vous aviez. Aucun des deux ne vous dit comment la version s’est comportée. Comparez les taux d’erreurs et les temps de réponse autour du marqueur pendant les premières minutes après un déploiement.
  • Gardez les vérifications honnêtes. bin/ci est un script que votre équipe peut modifier, et une étape commentée pour débloquer quelque chose a tendance à rester commentée. Il vaut la peine de relire config/ci.rb en revue de code, de la même façon que vous relisez un fichier de workflow.

​
Transcription

Transcrit à partir de la vidéo et légèrement édité : les sous-titres automatiques ont mal compris plusieurs noms de produits et d’API, et ceux-ci ont été corrigés.
0:02 Bonjour à tous, bienvenue dans une nouvelle leçon ici sur GoRails. Dans celle-ci, nous allons nous plonger dans le CI local qui est désormais livré avec Rails 8.1. Si vous allez voir le petit article qu’ils ont sur le site Ruby on Rails.org, vous pouvez voir quelques informations sur ce CI local. Ce travail a été mené par Jeremy Daer, ici chez 37signals. Et l’idée, c’est que vous n’avez pas besoin, vous savez, d’un ordinateur dans le cloud pour exécuter votre configuration de CI quand vous pouvez l’exécuter sur un ordinateur en local.0:39 C’est, dans de nombreux cas, bien plus rapide que de l’exécuter sur un ordinateur dans le cloud. Vous pouvez voir ici qu’il y a déjà un script CI par défaut configuré pour vous. Il se trouve dans config/ci.rb et est exécuté par la commande bin/ci. Voici ce fichier, d’accord ? C’est exactement le fichier tel qu’il est livré avec Rails.1:00 Et vous voyez qu’il y a une série d’étapes, et vous pouvez en ajouter d’autres si nécessaire. Mais il y en a déjà, vous savez, des étapes de base ici. Mais en réalité, tout ce qu’elles font, c’est exécuter d’autres scripts bin présents dans votre application, qui font des choses comme, vous savez, configurer l’environnement de développement, exécuter RuboCop sur votre code, exécuter Bundler Audit, Importmap Audit, et ainsi de suite. Vous voyez donc ici que vos tests s’exécutent. Et maintenant, il y a aussi une intégration GitHub optionnelle ici qui peut valider des pull requests pour vous.1:33 Disons, hé, le CI a été exécuté. Cette pull request est prête. Vous pouvez la fusionner si vous le souhaitez. Bien sûr, vous pourriez modifier ce message, mais voilà celui par défaut. Et pour l’utiliser, vous devez aussi installer cette extension de Basecamp, l’extension gh-signoff.1:49 Et, vous savez, c’est assez simple ici. Si le CI réussit, il va valider la pull request et dire que tout va bien. Sinon, il va la faire échouer et dire, hé, ne fusionnez pas ça. Il faut d’abord corriger quelque chose. Voyons donc ça en pratique.2:03 J’ai actuellement une application où nous avons ce script CI. Pour l’instant, j’ai commenté la partie GitHub. Exécutons-le simplement et voyons à quoi ça ressemble. Bon, je vais donc exécuter la commande bin/ci ici. Et on va voir qu’elle va exécuter toutes les étapes définies dans ce fichier config/ci.rb.2:22 Vous voyez ici que nous avons un échec. J’y reviendrai dans un instant. Quelque chose avec l’audit Importmap a échoué pour une raison ou une autre, on va regarder ça. Donc ici, en bas, vous voyez cet unique échec que nous avons eu, l’intégration continue a donc échoué en 20,23 secondes, ce qui est plutôt rapide. Et si on remonte, on voit ici notre unique échec.2:44 Il y a un audit de vulnérabilité Importmap qui a échoué. On peut donc regarder ça et voir quel est le problème. On peut le corriger dans notre code et relancer le CI. Je vais faire ça tout de suite. Bon, relançons le CI maintenant et voyons s’il réussit, échoue, ou autre chose.2:57 Bon, voilà, notre audit Importmap est passé. C’est donc bien. On devrait maintenant être tranquilles, puisque je crois que c’était le seul échec que nous avions. On a bien quelques avertissements de duplication ici, mais bon, on voit maintenant que l’intégration continue a réussi sur ce run.3:14 C’est donc très bien pour nous en local. Mais que faire si on doit communiquer ça sur GitHub ? On ouvre une pull request. J’ai donc fait une petite modification pour mettre à jour le readme de ce code, rien de bien important. On va juste s’en servir comme exemple pour exécuter le CI.3:27 Donc, pour utiliser les fonctionnalités gh-signoff, il nous faudra à nouveau avoir la GitHub CLI installée, ainsi que cette extension Basecamp. J’ai déjà la GitHub CLI installée. Je peux vous le montrer en exécutant simplement gh ici, et on voit qu’il s’agit bien de la CLI de GitHub. La seule chose qu’il nous reste à installer, c’est donc cette extension, que je n’ai pas encore installée. Copions donc cette commande et exécutons-la.3:53 On va donc installer cette extension gh-signoff de Basecamp. Bon, très bien. C’est fait. Et maintenant, décommentons la condition ici. D’accord, on enregistre.4:05 Et maintenant, relançons notre CI ici. Maintenant que le CI a été exécuté cette fois, on voit que la validation a échoué. Et la raison, c’est que même si j’ai créé une branche pour mettre à jour le readme, on a des modifications non commitées et non poussées en local. Il faut donc d’abord les committer. Je vais donc jeter un œil rapide au git status.4:27 Et là, oui, c’est bon. Ajoutons tout ça et commitons. On va dire mise à jour du readme et activation de la GitHub CLI dans le CI. Bon, maintenant on a un bon commit. Tout devrait être prêt ici.4:46 Et maintenant, relançons la commande bin/ci. Et voyons ce qui se passe cette fois. Bon, ça a encore échoué. On a commité nos modifications, mais on ne les a pas encore poussées. On voit donc ici que ça tombe probablement dans cette catégorie où on a encore des modifications non poussées.5:02 Poussons donc ça. Je vais ouvrir ça ici. Et puis on va juste ajouter une description. C’est un test très simple du nouveau CI local dans Rails 8.1. Créons donc une pull request ici.5:15 Relançons donc bin/ci ici. Voyons ce qui se passe. Bon, cette fois, on voit que, maintenant que les modifications ont été commitées et poussées, on obtient cette validation réussie ici. On voit donc qu’elle a validé le commit ici. Et on obtient le message, vous savez, validation accordée, tous les systèmes prêts pour la fusion et le déploiement, réussi en, vous savez, 0,8 seconde, intégration continue réussie au total en 23,37 secondes.5:43 Et maintenant, si on revient sur GitHub et qu’on fait défiler cette section vers le bas, si on regarde dans la section des vérifications, on peut effectivement voir que la vérification de validation a bien été, vous savez, poussée sur la branche ici. Ça indique qu’elle a validé, et on a la vérification. C’est donc bon, non ? Maintenant que ce CI local a été exécuté, on peut donc l’utiliser en combinaison avec la GitHub CLI pour valider des vérifications et dire, vous savez, hé, on a exécuté ça en local, tout a réussi, et on peut fusionner. On n’aurait donc pas vraiment besoin de refaire tout ça.6:20 Parce qu’on a déjà tout fait en local. On n’a pas besoin de refaire ça, vous savez, dans le CI GitHub ici. Donc, plutôt sympa tout ça. Une fois que tout est bien coordonné, cette histoire de validation est vraiment cool. Et aussi, vous savez, tout ce code ici dans le script CI, c’est quelque chose que vous pouvez exécuter, vous savez, vous-même, et étendre, et aller consulter, vous savez, vous pouvez aller voir n’importe lequel de ces fichiers, les scripts déjà présents dans votre application Rails.6:44 Donc RuboCop. Ils sont tous dans le répertoire bin de votre application Rails, déjà là. Vous savez, les trucs de Bundler, vous pouvez aussi les exécuter vous-même. Mais je veux dire, tout est là, disponible. Si vous devez aller voir ce code, vous pouvez simplement aller dans n’importe lequel de ces fichiers dans bin, et vous voyez qu’ils sont tous là.7:01 Par exemple, il y a un setup, RuboCop juste au-dessus. Bundler Audit est là aussi. Donc vraiment des choses cool ici avec l’ajout du CI local dans Rails 8.1. Donc vraiment, je dirais, allez jeter un œil, voyez si ça marche pour vous. Vous pourrez peut-être alléger une partie de votre configuration CI et simplement passer à ça, et peut-être ajouter ce dont vous avez besoin, ou retirer ce dont vous n’avez pas besoin, comme vous voulez, vous savez ?7:26 Donc voilà, j’espère que cette leçon vous a plu, et je vous dis à la prochaine.

​
À propos de ce tutoriel

Ce tutoriel résume un screencast GoRails sur le CI local de Rails 8.1, présenté par Collin. Le screencast est l’œuvre originale. GoRails le publie, ainsi que le reste de la série, sur gorails.com.