Preflight

Une règle sait comment vérifier quelque chose. Sa politique décide de son activation, de ses paramètres, de sa sévérité et de son effet bloquant. Deux projets utilisent le même assembly avec des budgets de taille différents, sans dupliquer le code. La logique se teste séparément et les exigences peuvent évoluer sans recompiler l’outil.

{
    "schemaVersion": 1,
    "pipeline": "projecta",
    "rules": {
        "core.presubmit.large-file": {
            "settings": {
                "maxBytes": 5242880
            }
        }
    },
    "targets": {
        "win64": {
            "rules": {
                "core.presubmit.large-file": {
                    "settings": {
                        "maxBytes": 2621440
                    }
                }
            }
        }
    }
}

Les règles déclarent leurs dépendances et s’exécutent par niveaux topologiques. Les vérifications indépendantes partagent un niveau ; les suivants attendent leurs prérequis. Si la vérification de la toolchain échoue, une sonde de compilation dépendante peut être ignorée au lieu de produire un autre échec prévisible.

L’attribution de la cause racine traverse les dépendances ignorées intermédiaires. Le message final désigne la toolchain absente, donnant un problème à résoudre plutôt qu’une liste de symptômes. L’étape sélectionne les racines du graphe sans éliminer les dépendances d’autres étapes.

J’ai choisi une barrière entre niveaux pour simplifier la propagation des échecs et la coordination. Une règle lente retarde le niveau suivant même si une partie pourrait déjà commencer. Ce coût est délibéré : l’exécution est plus facile à auditer et le rapport est ordonné par niveau et ID, indépendamment de l’ordre de fin des tâches.

Une convention de nommage peut bloquer un submit sans rendre la compilation inutile. Une sonde facultative peut être un prérequis technique sans que son échec rejette la soumission. Un seul booléen ne représente pas ces deux cas. Preflight sépare blocking, qui affecte le verdict et le code de sortie, de gating, qui arrête les règles dépendantes. La sévérité reste le niveau de communication.

Les politiques héritent de paramètres, appliquent des cibles explicites de plateforme/configuration et scellent des clés contre les modifications en aval. Les scellés s’accumulent dans la chaîne d’héritage : un projet ne peut pas retirer silencieusement une restriction de l’organisation. Les overlays locaux sont exclus de la CI.

La commande explain conserve l’origine des valeurs effectives : paquet, fichier, ligne et valeurs remplacées. Les axes de cible doivent être fournis explicitement pour correspondre à un bloc. Une configuration par défaut ne sélectionne donc pas silencieusement une autre politique de production.

La priorité doit être visible, car une valeur JSON ne suffit pas à expliquer la configuration effective. Sans provenance, enquêter sur une différence entre une machine et la CI obligerait à reconstruire l’héritage à la main. preflight explain fournit ces données à partir de la résolution elle-même.

Les règles implémentent IValidationRule via Preflight.Abstractions. Les accès aux fichiers, processus, modifications et politiques passent par les services de RuleContext, permettant des tests sans workspace réel. L’assembly des règles intégrées n’a pas de dépendance privilégiée envers Core.

Les plugins utilisent des contextes d’assembly séparés et collectables, en partageant le contrat avec l’hôte. Les versions de dépendances peuvent coexister ; les identifiants dupliqués et contrats incompatibles sont refusés explicitement. Cet isolement concerne les dépendances, pas la sécurité : les plugins restent du code approuvé par le responsable du pipeline.

Un paquet contient la politique, les assemblies des règles et un manifeste avec des empreintes SHA-256 par fichier et une plage de contrats compatible. L’ordre stable des entrées et des horodatages fixes rendent ses octets reproductibles. L’installation vérifie le paquet avant de le valider dans le stockage installé.

Le checkout déclare une plage de versions acceptées ; une machine peut fixer une version pour revenir en arrière. Installer un paquet ne déplace pas ce pin. Preflight ne récupère aucune mise à jour seul : la distribution utilise le canal d’artefacts du studio sans modifier les règles par surprise.

Passed, Warning, Failed, Errored, Skipped et NotApplicable ont des significations distinctes. Une règle sans élément applicable ne revendique pas un succès ; un crash se distingue d’un défaut du workspace. Console, JSON et SARIF présentent les mêmes données. Les codes de sortie distinguent une modification bloquée d’une configuration invalide et d’une erreur interne.

L’historique est un NDJSON local en ajout seul ; les statistiques de durée exigent assez d’observations. L’outil peut chronométrer un build, mais mesurer sa durée ne prouve ni sa validation ni le fonctionnement du logiciel.

Le déterminisme concerne le verdict et l’ordre des constats à entrées identiques, environnement inspecté et version de pipeline compris. La durée et le runId varient par construction ; comparer les octets exige de contrôler ces champs. Une même politique sur des machines avec des SDK différents peut correctement donner des résultats différents.

Le cache est activé explicitement et réservé aux règles fournissant une empreinte de leurs entrées. La clé comprend aussi la politique effective, l’étape, la cible, la génération du contrat et l’identité de l’assembly. Modifier une limite ou recompiler un plugin invalide donc l’ancien résultat. Les résultats en cache sont signalés, sans les présenter comme une nouvelle vérification.

Cette décision exige que l’auteur de la règle décrive les entrées pertinentes. Pour une sonde incapable de représenter son environnement de manière fiable, relancer est préférable à réutiliser une preuve incomplète. Le cache est désactivé par défaut.