Sujet : build
-
Construire des images de conteneur petites et reproductibles
Épingler les images de base par leur empreinte (digest), installer à partir de fichiers de verrouillage avec vérification des empreintes, ne copier que ce dont l'exécution a besoin, s'exécuter avec un utilisateur non root, ajouter un contrôle de santé, et garder les secrets hors des couches et des arguments de build.
-
Attestations de provenance de build : ce que la provenance SLSA enregistre et comment elle est vérifiée
La piste Build de SLSA évalue la fiabilité de la provenance d'un artefact, de « la provenance existe » (L1) jusqu'à une plateforme de build durcie (L3) ; la provenance est une attestation in-toto nommant les empreintes de l'artefact, le constructeur, le type de build et ses paramètres externes, et une personne consommatrice la vérifie face à une racine de confiance et à des valeurs attendues avant utilisation.
-
Un pipeline d'optimisation d'images au moment de la compilation : originaux, échelle de tailles, formats encodés et métadonnées retirées
Conserver les originaux hors de la racine web, en dériver chaque taille et format servis lors d'une étape de compilation reproductible, convertir en sRGB et retirer les métadonnées par défaut (sharp le fait sauf si keepMetadata est appelé ; cwebp n'en copie aucune sauf indication contraire via -metadata), nommer les sorties d'après la source et la largeur ou d'après un hachage de contenu, et vérifier avec exiftool qu'aucune donnée EXIF ou GPS ne subsiste.
-
Empaqueter un projet Python avec pyproject.toml
pyproject.toml déclare le système de build, les métadonnées et les dépendances dans un unique fichier standard (PEP 517/518/621) ; grâce à lui, tout outil conforme peut construire, installer et figer le projet sans setup.py.
-
Builds reproductibles et dépendances figées
Un build est reproductible lorsque la même source et le même environnement de build produisent une sortie identique bit à bit ; des fichiers de verrouillage (lockfiles) avec empreintes, des images de base figées et des horodatages fixes en sont les étapes pratiques.
-
Les exécuteurs de tâches au-delà de make : just, les scripts npm et Invoke pour les commandes de projet
Un exécuteur de tâches donne à un projet un endroit unique pour ses commandes, afin que les personnes, les agents et l'intégration continue invoquent les mêmes noms ; just stocke des recettes dans un justfile avec une syntaxe proche de make et sans logique d'horodatage, les scripts npm vivent dans package.json avec des hooks pre et post, et Invoke transforme des fonctions @task d'un tasks.py en ligne de commande. Choisir celui qui n'exige pas de chaîne d'outils supplémentaire, garder les recettes courtes, et laisser l'intégration continue les appeler.
Lisible par machine : JSON