Configuration de l'intégration continue
Décidez ce qui s'exécute sur chaque push et sur chaque demande de changement, puis écrivez-le dans la syntaxe comprise par le forge du projet. Les décisions de ce fichier sont indépendantes du forge : détectez l'écosystème, décidez ce qui doit s'exécuter, choisissez une matrice, décidez de la mise en cache. La syntaxe qui exprime ces décisions ne l'est pas, elle se trouve donc dans references/github-actions.md pour GitHub Actions et references/gitlab.md pour GitLab CI/CD. Lisez le fichier de référence correspondant avant d'écrire une configuration ; n'écrivez pas la syntaxe d'un forge en traduisant les mots-clés de l'autre, car les deux ont des formes différentes pour les déclencheurs, les matrices et la mise en cache.
Périmètre
Ce skill possède ce qui s'exécute : quelles vérifications sont effectuées, sur quels déclencheurs, avec quelles versions et quelle mise en cache. Il partage les fichiers de workflow et de pipeline qu'il écrit avec deux autres skills, et la frontière entre eux est la zone de règle, pas une description de fichiers.
Les règles CI ci-dessous (R-CI-*) appartiennent ici. Les règles SEC, la posture de sécurité des mêmes fichiers (tels que les SHA d'actions épinglées, les permissions minimales, les mises à jour de dépendances, la protection de branche et les images épinglées) appartiennent à oss-harden. Les règles REL, la publication d'un artefact construit vers un registre avec publication de confiance, provenance et une porte d'approbation, appartiennent à oss-publish. N'ajoutez pas de bloc permissions:, n'épinglez pas de SHA, ne configurez pas de protection de branche, et n'écrivez pas de tâche de publication tout en travaillant avec ce skill ; notez que le projet en a besoin et confiez le travail au skill propriétaire.
Le déploiement d'un site statique construit vers l'hébergement Pages du forge lui-même est également quelque chose qui s'exécute sur un push, donc cela reste ici plutôt qu'avec oss-publish, qui possède les versions de registre. Aucune règle ne l'exige : un projet publie un site parce qu'il en a un, donc il n'est écrit que là où le dépôt construit un site et que l'utilisateur demande le déploiement.
Principes
Vérifiez tout avant d'ajouter une étape, un secret ou une valeur de configuration : lisez le dépôt réel plutôt que de deviner sa forme. Demandez quand quelque chose est incertain au lieu d'inventer une réponse plausible.
Appelez l'automatisation propre du projet au lieu d'écrire de la logique shell dans le pipeline. Une étape qui exécute npm test au lieu de jest --coverage --ci garantit que le pipeline et l'ordinateur d'un contributeur exécutent la même commande, ce que R-CI-02 vérifie. Lorsqu'aucune automatisation de ce type n'existe, demandez s'il faut l'ajouter au projet ou recourir à des commandes en ligne.
Présentez les choix de politique plutôt que de les deviner, même lorsque le dépôt contient déjà des tests, un Dockerfile ou un pipeline. Ce qui s'exécute sur une demande de changement, ce qui déclenche une construction de version et comment le déploiement se produit sont des décisions que l'utilisateur prend ; le code ne vous dit que ce qui est possible, pas ce qui est souhaité.
Processus
Étape 1 : Détecter le forge
Recherchez un répertoire .github/workflows/ ou un fichier .gitlab-ci.yml existant, vérifiez le remote git pour un hôte github.com ou gitlab, ou demandez directement si aucun signal n'est présent. Cela décide quel fichier de référence régit les étapes 6 et 7. Si l'utilisateur indique explicitement le forge, faites-lui confiance plutôt qu'à tout signal trouvé dans le dépôt.
Étape 2 : Analyser le dépôt
Identifiez le langage et l'environnement d'exécution à partir des fichiers source et du manifeste du paquet, et notez la plage de versions que le projet prétend supporter ; la matrice à l'étape 4 doit tout couvrir, y compris la version supportée la plus ancienne et la plus récente, conformément à R-CI-03.
Trouvez chaque commande applicable de lint, test, vérification de type et construction que le projet définit déjà, que ce soit des scripts de gestionnaire de paquets, un Makefile, un Rakefile, ou un outil comme tox ou just, et lisez-les suffisamment en détail pour connaître leurs arguments et leurs effets de bord. N'inventez pas de classe de vérification manquante : un dépôt de documentation peut n'avoir aucune construction, et un petit script peut n'avoir aucun linter. Si le dépôt a un guide CONTRIBUTING, ses commandes et l'automatisation du projet doivent être en accord ; résolvez tout conflit avant de copier l'un ou l'autre dans CI.
Lisez toute configuration CI existante avant de la modifier, afin de savoir si vous devez l'étendre ou la remplacer.
Identifiez chaque fichier de verrouillage que le projet valide, tel que package-lock.json, Gemfile.lock, poetry.lock ou Cargo.lock, et quel cache de téléchargement du gestionnaire de paquets chaque commande d'installation peut réutiliser en toute sécurité. Ne supposez pas qu'un répertoire de dépendances installées est un cache.
Trouvez .env.example et recherchez dans le source les variables d'environnement requises, afin qu'une étape nécessitant un secret soit identifiée avant la génération plutôt qu'après un échec d'exécution.
Étape 3 : Présenter les résultats et demander
Résumez ce que l'étape 2 a trouvé, puis demandez les choix que le code seul ne peut pas répondre : ce qui doit s'exécuter sur une pull request ou une merge request, ce qui doit déclencher une construction de version, et si la CI existante doit être étendue ou remplacée. Ne demandez que ce qui s'applique à ce projet ; un projet sans Dockerfile ne reçoit pas de question sur un registre.
Lorsque l'étape 2 a trouvé une construction qui produit un site statique, demandez si elle doit également être déployée, et où. Un site peut être construit comme une vérification et jamais publié, donc traitez une construction statique comme une question plutôt que comme un consentement à en déployer un.
Étape 4 : Choisir la matrice
Construisez la matrice de versions à partir des lignes de version supportées identifiées à l'étape 2, pas à partir d'une version unique épinglée. Incluez chaque ligne de version majeure ou mineure maintenue que le projet prétend supporter. Un projet sans plage de support déclarée reçoit un pipeline à version unique au lieu d'une matrice inventée ; ne fabriquez pas de revendications de support que le manifeste ne fait pas. Si une plage est continue et inclut des lignes de version que le projet n'a pas l'intention de supporter, corrigez la plage déclarée plutôt que de tester silencieusement un sous-ensemble.
Étape 5 : Décider de la mise en cache
Mettez en cache uniquement les données de téléchargement du gestionnaire de paquets ou un autre répertoire que la documentation officielle de l'outil indique comme sûr à réutiliser. Préférez l'action de configuration d'exécution officielle du forge lorsqu'elle supporte le gestionnaire de paquets détecté et hache le fichier de verrouillage. Sinon, indexez un cache explicite sur le fichier de verrouillage plus chaque limite de compatibilité qui modifie son contenu, comme le système d'exploitation, l'architecture, l'environnement d'exécution et le gestionnaire de paquets. Une clé de secours est facultative et ne doit pas franchir l'une de ces limites. Un projet sans fichier de verrouillage ou sans cache de téléchargement réutilisable n'a pas d'étape de cache.
Étape 6 : Écrire la configuration
Ouvrez le fichier de référence pour le forge choisi à l'étape 1 et suivez sa syntaxe exactement. Les deux fichiers de référence couvrent le déclenchement sur push vers la branche par défaut et sur chaque demande de changement (R-CI-01), un délai d'attente sur chaque tâche avec annulation des exécutions remplacées sur la même branche (R-CI-05), et les décisions de cache de l'étape 5 (R-CI-04). Les deux comportent également une section de déploiement Pages, utilisée uniquement lorsque l'étape 3 a établi que le projet en veut une. Aucun fichier de référence ne couvre les permissions, l'épinglage de SHA ou la publication ; ceux-ci restent en dehors du fichier que vous écrivez ici.
Étape 7 : Valider avant de présenter
Confirmez que la configuration est syntaxiquement valide avec le validateur officiel du forge lorsqu'il est disponible, et confirmez que chaque commande qu'elle appelle existe et réussit localement dans le même ordre. Pour GitLab, utilisez CI Lint avec la configuration incluse développée. Pour GitHub, inspectez le workflow dans l'éditeur Actions ou poussez-le sur une branche lorsque l'utilisateur a autorisé ce changement externe ; un analyseur YAML générique ne peut pas valider les expressions GitHub ou la sémantique des workflows. Listez les secrets dont le pipeline a besoin, avec la commande pour ajouter chacun d'eux, sans exécuter cette commande. Confirmez que la matrice correspond à chaque ligne de version supportée et que chaque tâche comporte un délai d'attente et participe à l'annulation des exécutions remplacées lorsque c'est sûr.
Étape 8 : Présenter le résultat
Affichez le fichier généré, un bref résumé de ce qui a été détecté et décidé, la liste des secrets à configurer, et tout ce qui reste à définir par l'utilisateur au niveau du dépôt ou du projet, comme la protection de branche ou les approbateurs d'environnement, en nommant le skill qui le possède plutôt que de tenter de le faire ici.
Règles possédées par ce skill
R-CI-01 : CI s'exécute sur chaque push vers la branche par défaut et sur chaque demande de changement
R-CI-02 : CI exécute les mêmes commandes de lint, test et construction que le guide de contribution donne aux humains
R-CI-03 : La matrice de test couvre chaque version de l'environnement d'exécution que le projet prétend supporter
R-CI-04 : Les caches de dépendances sont indexés sur le fichier de verrouillage
R-CI-05 : Chaque tâche a un délai d'attente, et les exécutions remplacées pour la même branche sont annulées