Sévérités

Chaque règle de validation a une sévérité fixe. La sévérité décide si une anomalie est un défaut de conformité, un problème de qualité, ou une suggestion de bonne pratique — et, en CI, si le pipeline passe au rouge.

Les trois niveaux

ERROR

Votre flux n’est pas conforme à la spec GTFS Schedule. Un consommateur en aval (Google Maps, Apple Maps, un planificateur d’itinéraire) va probablement rejeter le flux ou ignorer silencieusement les lignes fautives.

Exemples :

• Une ligne de stop_times référence un stop_id absent de stops.txt.
• Une colonne requise manque dans un fichier requis.
• Une valeur route_type est hors de l’énumération documentée.

Toute anomalie ERROR dans une exécution validate provoque une sortie avec code 1 (COMMAND_FAILED).

WARNING

Le flux est techniquement conforme, mais quelque chose sent mauvais. Les consommateurs l’accepteront, mais il va probablement produire un comportement incorrect en aval.

Exemples :

• Un service_id dans calendar_dates.txt sans ligne correspondante dans calendar.txt (autorisé par la spec ; reste une erreur courante).
• Deux lignes partagent le même route_short_name dans un même opérateur.
• Un point de tracé d’un trajet est à des centaines de mètres du plus proche arrêt.

Par défaut, les warnings ne font pas échouer la validation.

INFO

Suggestion de bonne pratique. Le flux est conforme et cohérent ; l’anomalie est cosmétique ou stylistique.

Exemples :

• route_short_name absent sur une ligne qui n’a que route_long_name.
• Colonnes inconnues (champs d’extension non définis par la spec) — unknown_column.
• Entités non utilisées (par ex. une forme non référencée par un trajet).

Les INFO ne font jamais échouer la validation et n’affectent pas le code de retour sauf promotion explicite via --min-severity.

Promotion via --min-severity

--min-severity filtre et reclassifie. Avec --min-severity warning, tout ce qui est en dessous est retiré du listing et des compteurs du résumé. Deux effets pratiques :

1. La sortie est plus lisible — seules les anomalies actionnables apparaissent.
2. Le statut PASS/FAIL bascule quand les avertissements précédemment filtrés deviennent les anomalies les plus sévères restantes.

En pratique :

# Par défaut : seule une ERROR échoue.
gapline validate -f gtfs.zip

# Strict : WARNING échoue aussi.
gapline validate -f gtfs.zip --min-severity warning

# Plus strict : même les INFO comptent.
gapline validate -f gtfs.zip --min-severity info

Utilisez --min-severity warning en CI si vous voulez que le pipeline passe au rouge sur tout ce qui a l’air suspect, pas seulement sur les violations de spec.

Désactiver une règle complètement

Parfois une règle est trop stricte pour votre flux — par exemple une ligne interne qui chevauche volontairement un block avec un autre trajet. Désactivez-la avec --disable-rule <RULE_ID> :

gapline validate -f gtfs.zip --disable-rule block_id_trip_overlap

Trouvez chaque ID avec gapline rules list. L’autocomplétion shell suggère les IDs dynamiquement.

Pour pinner la désactivation, fixez la liste dans gapline.toml :

gapline.toml

[validation]
disabled_rules = ["block_id_trip_overlap", "duplicate_coordinates"]

--disable-rule en ligne de commande ajoute à la liste de config — il ne la remplace pas.

Patterns courants

Objectif	Flag
Échec seulement sur ERROR (défaut).	(aucun)
Échec aussi sur WARNING.	--min-severity warning
Échec sur tout.	--min-severity info
Garder la politique par défaut mais faire taire une règle précise.	--disable-rule <RULE_ID>
Faire taire une règle pour ce run seulement, en plus de la liste config.	--disable-rule <RULE_ID> (ajouté)

Voir aussi

• gapline validate — références --min-severity et --disable-rule.
• gapline rules list — trouver un ID de règle à désactiver.
• Règles de validation — catalogue complet avec sévérités.
• Concepts / Codes de retour.