Imposer l’utilisation de fichiers de verrouillage pour les dépendances d’action

Exiger des fichiers de verrouillage vous donne une assurance cohérente et auditable que chaque flux de travail exécute du code vérifié, sans demander à chaque équipe d’adopter la pratique elle-même. Pour une introduction, consultez Fichiers de verrouillage des dépendances du workflow.

Ce guide vous aide à mener un projet pilote dans les référentiels sélectionnés et à configurer des automatisations pour maintenir les fichiers de verrou à jour. Lorsque vous êtes certain que les fichiers de verrouillage fonctionnent comme prévu et que vous n’introduisez pas de frictions pour les développeurs, vous pouvez appliquer la stratégie Exiger un fichier de verrouillage.

Prerequisites

Avant d’appliquer des fichiers de verrouillage de flux de travail et de créer des processus pour les maintenir à jour, le fichier de verrouillage doit exister dans vos référentiels. Pour les instructions, consultez Verrouillage des dépendances d’action dans les flux de travail d’un dépôt.

1. Testez la stratégie « exiger un lockfile »

La stratégie Require lockfile bloque les exécutions de flux de travail ciblés qui incluent des dépendances d’action, mais qui ne sont pas enregistrées dans le fichier de verrouillage du dépôt. Pour configurer la stratégie, consultez Gestion de l’exécution des workflows GitHub Actions.

Effectuez un projet pilote avant d’appliquer cette politique dans tous les référentiels. Vous devriez :

• Limitez la stratégie à des dépôts spécifiques ayant adopté les fichiers de verrouillage.
• Ciblez des flux de travail spécifiques qui ont été ajoutés au fichier de verrouillage. Procédez ainsi jusqu’à ce que tous les flux de travail soient intégrés et que vous ayez des processus en place pour vous assurer que les nouveaux flux de travail sont intégrés automatiquement.
• Commencez par la stratégie en mode Évaluer et analysez les résultats sous Observations de la stratégie

2. Maintenez les fichiers de verrouillage à jour

L’application des règles fonctionne uniquement si les fichiers de verrouillage restent à jour. Ajoutez des automatisations afin que les développeurs n’aient pas besoin de se rappeler d’exécuter la commande de verrouillage chaque fois qu’ils créent ou modifient des flux de travail.

Les sections suivantes donnent des exemples pour empêcher les fichiers de verrouillage obsolètes à différents points du cycle de vie du développement.

• Conservez le fichier à jour en activant la fonctionnalité Dependabot Dependabot version updates et en créant un flux de travail pour exécuter la commande de verrouillage.
• Ajoutez une skill et un hook de pré-validation pour raccourcir la boucle de commentaires pour les développeurs.

Pour obtenir des implémentations prêtes à être copiées du flux de travail et de la compétence, consultez le référentiel gh-actions-lock .

Dependabot mises à jour de version

Lorsque Dependabot met à jour la version d’une action, elle régénère l’entrée de fichier de verrouillage correspondante dans la même pull request.

Vous n’avez pas besoin d’une configuration au-delà du fait que Dependabot gère GitHub Actions les dépendances. Consultez « Maintenir vos actions à jour avec Dependabot ».

Dependabotne prendra pas en charge encore un flux de travail qui n’a encore aucune entrée dans le fichier de verrouillage. Cette option conserve donc la couverture plutôt que de l’étendre.

Flux de travail dédié GitHub Actions

Lorsque quelqu’un ajoute ou modifie un flux de travail, exécutez un autre flux de travail qui exécute la commande de verrouillage. Déclenchez le flux de travail lors de modifications de .github/workflows/** et de tout fichier action.yaml ou action.yml, puis donnez-lui deux tâches :

• Tâche de mise à jour qui régénère le fichier de verrouillage sur push et valide le résultat. Ce travail nécessite contents: write des autorisations, et vos règles ou ensembles de règles de branche doivent autoriser GitHub Actions l’envoi (push) sur les branches sur lesquelles il s’exécute.
• Tâche de vérification qui s’exécute gh actions-lock --verify sur les pull requests. Cela doit se terminer avec une erreur si le fichier de verrouillage est obsolète, ce qui le rend utile pour une vérification requise.

Une Copilot compétence

Lorsque Copilot modifie un fichier de flux de travail, dites-lui d’exécuter la commande pour mettre à jour le fichier de verrouillage dans le même ensemble de modifications.

L’agent doit indiquer à Copilot de régénérer le fichier de verrouillage avec l’interface CLI chaque fois qu’il modifie un flux de travail ou une action locale, et ne jamais modifier le fichier de verrouillage directement. Il ne couvre que les modifications effectuées avec Copilot, donc considérez-le comme une solution pratique plutôt que comme un contrôle. Consultez « À propos des compétences de l’agent ».

Un hook de pre-commit

Cela intercepte un fichier de verrou obsolète avant qu’un commit n’existe, ce qui est le retour le plus tôt possible qu’un développeur puisse obtenir.

Utiliser gh actions-lock --verify-local --no-fix dans le hook. Il fonctionne hors connexion, n’a pas besoin d’authentification et est assez rapide pour s’exécuter sur chaque validation. Cette commande confirme que chaque dépendance a une entrée de fichier de verrouillage, mais ne vérifie pas à nouveau les versions épinglées par rapport à GitHub.

3. Configurer un processus de révision pour les modifications de lockfile

Un fichier de verrouillage n’est qu’un contrôle de sécurité si quelqu’un lit le diff. Un SHA de commit modifié vous indique que le code que vos workflows exécutent a changé.

1. Ajoutez .github/workflows/actions.lock à votre fichier CODEOWNERS afin que l’équipe responsable de la sécurité de build soit automatiquement sollicitée pour effectuer la révision. Consultez « À propos des propriétaires de code ».
2. Configurez une règle de protection de branche ou un ensemble de règles de référentiel pour exiger l’approbation d’un propriétaire de code.
3. Indiquez aux réviseurs ce qu’il faut rechercher. Pour des instructions détaillées, consultez Verrouillage des dépendances d’action dans les flux de travail d’un dépôt.

4. Appliquer la politique

Lorsque vous êtes certain que les fichiers de verrouillage sont en place et resteront à jour, modifiez l’état d’application de la stratégie Exiger un fichier de verrouillage sur Actif, et assurez-vous que tous les référentiels et flux de travail intégrés sont ciblés.

Laissez en place la vérification de l’étape 2. La stratégie bloque une exécution de flux de travail qui n’a pas de fichier de verrouillage valide, mais une vérification indique à un auteur que son fichier de verrouillage est obsolète pendant qu’il travaille toujours sur la pull request.