Skip to main content
Un pack est composé de trois fichiers attachés à une release GitHub. failproofai pack build génère les trois à partir d’un fichier de politiques que vous possédez déjà.

​
1. Écrire les politiques

Un seul fichier, utilisant la même API que n’importe quelle politique personnalisée. Deux champs supplémentaires sont importants pour un pack :
defaultEnabled vaut false par défaut si vous l’omettez. Un simple failproofai pack add n’active que ce que vous avez marqué — activer en bloc toutes les politiques d’un inconnu sans supervision n’est pas une décision que l’installeur devrait prendre à la place de son utilisateur.
L’entrée doit être un fichier unique et autonome. Seule l’entrée est épinglée par son condensat, donc un pack qui importe des fichiers locaux ne pourrait pas honnêtement prétendre que le condensat couvre ce qui s’exécute. Bundlez d’abord (esbuild, bun build, rollup) et construisez le pack à partir du bundle — pack build refuse une importation locale plutôt que de livrer une promesse qu’il ne peut pas tenir.

​
2. Construire les assets de la release

Cette commande génère trois fichiers et valide chaque politique avec les propres règles du chargeur — ainsi, un pack qui ne pourrait jamais s’installer échoue ici, là où vous pouvez corriger le problème : Refusés à la construction : un id qui n’est pas publisher/name, un nom de politique contenant /, une politique déclarant alwaysOn, une description, une category ou un match manquants, une entrée qui n’enregistre rien, et une entrée qui importe des fichiers locaux.

​
3. Attacher les fichiers à une release

Taguez la release avec la même version que celle utilisée lors de la construction, et attachez les trois fichiers comme assets de la release :
N’importe qui peut désormais l’installer :
Les noms des assets sont fixes — c’est à partir d’eux que le CLI du consommateur construit ses URLs, sans appel API ni mécanisme de découverte.

​
Publier une nouvelle version

Construisez avec le nouveau --version, taguez une nouvelle release, attachez à nouveau les trois assets. Les consommateurs exécutent le même pack add et conservent le sous-ensemble qu’ils avaient choisi ; une politique qu’ils ont désactivée reste désactivée après la mise à jour. Changer le nom d’une politique est un changement cassant : une machine qui l’avait désactivée désactive un nom qui n’existe plus, et le nouveau nom arrive avec ce que defaultEnabled indique.

​
Ce que vos utilisateurs vous font confiance

SHA256SUMS se trouve dans la même release que l’artefact, ce qui prouve que les octets sont bien ceux que vous avez publiés — mais pas qui vous êtes. Quiconque peut écrire dans le dépôt peut écrire les deux fichiers. La protection de vos utilisateurs réside dans le fait que le condensat est épinglé au moment de l’installation, ce qui empêche ce que vous avez publié de changer à leur insu par la suite. Publiez depuis un dépôt dont vous contrôlez les accès en écriture, et traitez une release de pack comme la publication d’un package.

​
Observer avant d’appliquer

Un manifeste peut déclarer "effect": "observe". Ces politiques s’exécutent et leurs verdicts sont enregistrés puis ignorés — rien n’est bloqué. C’est la façon de mesurer une nouvelle règle face au trafic réel avant qu’elle ne puisse interrompre le travail de quiconque.