# Lancer Lockpick en CI Contrôlez votre site avec une analyse Pulse lors de la publication d’une version, et faites échouer le build lorsque des points graves sont ouverts. La CLI s’exécute dans toute CI disposant de Node.js 20.9 ou d’une version ultérieure. Une analyse Pulse en CI utilise à chaque exécution une analyse Pulse de votre quota mensuel, comme son lancement dans Lockpick. Lancez-la donc lors de la mise en production plutôt qu’à chaque envoi de code. ## Écrire le workflow Depuis votre dépôt, avec la CLI connectée : ```bash title="Terminal" lockpick ci init ``` Elle écrit `.github/workflows/lockpick.yml`. Le workflow s’exécute lorsque vous publiez une version et lorsque vous le lancez depuis l’onglet Actions. Il lance une analyse Pulse sur le site, attend le résultat, et échoue lorsque des points à corriger ouverts ont une gravité `high` ou plus. Il fixe la version de la CLI avec laquelle il a été écrit. * `--fail-on critical`, `high`, `medium` ou `low` définit le seuil. * `--dry-run` affiche le workflow sans l’écrire. * `--file ` l’écrit ailleurs, et `--force` remplace un fichier existant. Si la CLI est connectée à une adresse locale, `ci init` vous en avertit : les runners GitHub ne peuvent atteindre qu’une adresse Lockpick publique. Passez `--host` avec cette adresse. ## Ajouter la clé Le workflow lit sa clé dans le secret de dépôt `LOCKPICK_KEY`. Utilisez une clé autorisée à lancer des analyses Pulse. ```bash title="Terminal" gh secret set LOCKPICK_KEY ``` > **Careful** > > Une clé peut faire ce que vous avez autorisé lors de votre connexion. > Conservez-la dans le magasin de secrets de votre CI, jamais dans votre dépôt, > et révoquez-la dans Lockpick sous **Ajouter à votre IA**, dans l’onglet > **CLI et clés**, lorsque vous n’en avez plus besoin. ## Faire échouer sur les points à corriger partout `--fail-on` fonctionne sur toute commande qui se termine par une analyse terminée : `lockpick pulse`, `lockpick recheck`, `lockpick watch`, `lockpick deep start` et `lockpick findings`. `lockpick ci check ` l’applique à une analyse déjà terminée, sans en lancer une ni utiliser votre quota, et peut aussi échouer selon son âge (`--max-age-hours`) ou sa couverture (`--min-coverage`). Lorsque des points à corriger ouverts atteignent le seuil, la commande se termine avec le code 8, ce qui permet à n’importe quelle CI d’arrêter le build : ```bash title="Terminal" lockpick pulse --fail-on high --timeout 900 ``` En CI, la CLI affiche une ligne à chaque changement d’état d’une analyse, au lieu d’une progression en direct, et `--json` n’affiche que le résultat. Définissez `FORCE_COLOR=1` pour les couleurs dans un journal qui les affiche. ## Codes de sortie de la CLI et du script d’analyse de version La CLI et le [script d’analyse de version](/fr/docs/protect/release-scans) autonome utilisent des contrats de sortie différents. Vérifiez lequel votre job exécute. | Résultat | CLI `lockpick` | Script d’analyse de version autonome | | ----------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------ | | Terminé sous le seuil de points à corriger | 0 | 0 | | Des points à corriger ouverts ont atteint le seuil | 8 | 1 | | L’analyse a échoué ou une autre erreur s’est produite | Voir [codes de sortie de la CLI](/fr/docs/cli/install#exit-codes) | 1 | Le script d’analyse de version utilise une clé CI limitée à un site (`LOCKPICK_CI_KEY`) ; la CLI utilise `LOCKPICK_KEY` et les autorisations que vous avez accordées.