Les lockfiles Actions passent en GA : que prouve un voyant vert ?
Une PR peut conserver la même version dans uses alors que le code visé change. Un tag peut être déplacé vers un autre commit. GitHub a annoncé la disponibilité générale des lockfiles le 28 octobre. Après la préversion, il faut comprendre ce que chaque vérification établit réellement.
Des références lisibles, des commits enregistrés
.github/workflows/actions.lock associe les références des actions aux commits à exécuter. Le fichier est généré par gh actions-lock et proposé sur Free, Team et GitHub Enterprise Cloud, y compris avec résidence des données. L’adoption peut se faire workflow par workflow. On examine ensemble le fichier généré et les modifications du workflow, sans assembler le lockfile à la main.
Prenons un exemple fictif : demo/build@v1 pointe vers A, puis vers B. Résoudre seulement cette référence peut sélectionner un autre code lors du prochain lancement. Le lockfile conserve le commit enregistré. L’illustration n’est pas un test réel. Un commit devenu inaccessible depuis le tag ou la branche enregistré peut être refusé à l’exécution.
Que confirme la vérification hors ligne ?
gh actions-lock --verify-local vérifie sans réseau la couverture des références uses par des entrées. C’est utile avant un commit, mais cela ne confirme pas la provenance. gh actions-lock --verify effectue cette vérification en ligne ; le runner la répète au démarrage du job. Les deux voyants verts n’ont donc pas la même portée.
Une PR parallèle peut ajouter une action sans mettre à jour le fichier. La couverture locale peut repérer cet oubli. La présence de toutes les entrées ne prouve ni leur provenance ni la sûreté du code. La deuxième illustration résume la documentation ; la CLI n’a pas été installée ou exécutée pour cet article.
Les workflows réutilisables changent de périmètre
Les dépendances transitives des actions sont couvertes, mais pas les appels via jobs.<job_id>.uses. Il faut référencer ces workflows par leur SHA complet. Leurs actions internes dépendent du lockfile du dépôt où ils sont définis, pas de celui de l’appelant.
Si un dépôt applicatif appelle le déploiement d’un dépôt plateforme, son seul actions.lock ne décrit pas les actions de la plateforme. Il faut rapprocher le SHA d’appel et les dépendances de celle-ci. Image du runner, paramètres et secrets restent aussi des entrées distinctes : fixer une action ne fige pas tout l’environnement.
Lire ensemble les deux fichiers d’une mise à jour
Lorsqu’il met à jour une action d’un workflow adopté, Dependabot régénère l’entrée correspondante dans la même PR. On peut comparer version lisible et commit réel. --relock avance les références déplacées et écrit les fichiers ; ce n’est pas une simple vérification en lecture seule. La revue du code reste nécessaire.
Require lockfile permet d’imposer l’adoption, sans effacer les frontières entre dépôts. Commencer par un workflow aide à comprendre génération, revue et validation en ligne. Au prochain voyant vert, demandez-vous précisément s’il atteste la couverture, la provenance ou une revue du code choisi.