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. Vous n’avez pas besoin d’être administrateur pour créer un fichier de verrouillage. Toute personne disposant d’un accès en écriture à un dépôt peut le faire. Vous pouvez donc déléguer l’intégration des équipes à des équipes individuelles avant d’appliquer la stratégie de manière centralisée.

Si vos flux de travail appellent des flux de travail réutilisables à partir d’autres référentiels, vérifiez que ces référentiels sources sont également intégrés. Le fichier de verrouillage du dépôt appelant ne les inclut pas. Si un flux de travail réutilisable appelé n’est pas ajouté dans son propre référentiel, la stratégie Require lockfile bloque l’exécution du flux de travail appelant.

1. Piloter la politique « Exiger un fichier de verrouillage »

La règle Exiger un fichier de verrouillage bloque les exécutions de workflows ciblés qui ne sont pas répertoriés dans le fichier de verrouillage du dépôt, y compris les workflows sans uses: dépendances.

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 sont pris en charge par le fichier de verrouillage, jusqu’à ce que tous les flux de travail soient pris en charge et que vous disposiez de processus automatisés pour prendre en charge les nouveaux.
• Commencez par la politique en mode Évaluer et analysez les résultats sous Aperçus de la politique.

Exiger un fichier de verrouillage est une stratégie distincte de Exiger que les actions soient épinglées à un SHA de commit complet. Vous pouvez conserver les deux activés pendant votre déploiement. Pour configurer la stratégie et voir comment les deux interagissent, consultez Gestion de l’exécution des workflows GitHub Actions.

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 verrou obsolètes à différents points du cycle de vie du développement :

• Conservez le fichier à jour en activant Dependabot.
• Créez un workflow pour exécuter la commande de verrouillage et la vérifier dans les exigences de votre pull request.

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.

Un flux de travail dédié ou Copilot

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 protection des branches doivent autoriser GitHub Actions à effectuer un push sur les branches sur lesquelles le workflow s’exécute. L’écriture dans le fichier de verrouillage nécessite la portée OAuth workflow, donc vérifiez que votre outil dispose de cette portée.
• 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.

Pour obtenir un exemple de flux de travail prêt à l’emploi, consultez verify-lockfile.yml dans le gh-actions-lock référentiel. Si vous utilisez Copilot pour modifier des workflows, vous pouvez également le configurer pour régénérer le lockfile dans le même ensemble de modifications. Consultez le skill gh-actions-lock et le Compétences de l’agent.

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é, en particulier, vous indique que le code qu’exécutent vos workflows 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. Vérifiez que tous les dépôts et flux de travail ajoutés sont ciblés.

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

Si un contrôle de vérification échoue, consultez le guide de résolution des problèmes de gh-actions-lock dans le référentiel gh-actions-lock.