Configuration

gapline lit ses réglages depuis un fichier TOML. Posez un gapline.toml à côté de votre flux et vous n’aurez plus à retaper -f, --format, ou --min-severity sur chaque commande. Cette page couvre où poser le fichier et quoi y mettre ; référence / fichier de configuration liste chaque clé acceptée.

La chaîne de lookup

Les réglages résolvent en quatre couches, priorité décroissante. Chaque couche surcharge la suivante — le CLI a toujours le dernier mot.

Priorité	Couche	Usage typique
1	Flags CLI (--feed, --format, --min-severity…)	Surcharges ponctuelles pour un run.
2	./gapline.toml dans le répertoire courant	Défauts par projet — à commiter avec le flux.
3	Config globale utilisateur (chemins ci-dessous)	Préférences personnelles partagées entre projets.
4	Valeurs par défaut du binaire	Ce que vous obtenez sans config.

--config PATH en CLI remplace la couche 2 par le fichier pointé. La couche 3 reste consultée en priorité inférieure — les overrides locaux gagnent toujours.

Où poser le fichier

Linux / macOS

• Local — ./gapline.toml dans le répertoire où vous lancez gapline.
• Global — ~/.config/gapline/config.toml.

mkdir -p ~/.config/gapline
touch ~/.config/gapline/config.toml

Windows

• Local — .\gapline.toml dans le répertoire où vous lancez gapline.
• Global — %APPDATA%\gapline\config.toml.

New-Item -ItemType Directory -Force "$env:APPDATA\gapline" | Out-Null
New-Item -ItemType File -Force "$env:APPDATA\gapline\config.toml" | Out-Null

Chemin explicite

Pointez --config vers n’importe quel TOML. Utile en CI, quand le fichier vit hors du projet.

gapline --config ci/gapline.ci.toml validate -f data/gtfs.zip

Exemple minimal

Ce que la plupart des projets veulent. Un chemin de flux, un format par défaut, et vous arrêtez de les retaper à chaque commande.

gapline.toml

[default]
feed   = "./data/gtfs.zip"
format = "json"

# Avec la config ci-dessus, validate tourne sur ./data/gtfs.zip et produit du JSON.
gapline validate -o report.json

Exemple plus complet

Quand le projet prend une cadence (sévérité stricte en CI, quelques règles bruyantes, des seuils de vitesse spécifiques à votre flux ferroviaire), épinglez-les dans la config.

gapline.toml

[default]
feed   = "./data/gtfs.zip"
format = "json"

[validation]
min_severity   = "warning"
disabled_rules = ["block_id_trip_overlap"]

[validation.thresholds.speed_limits]
rail_kmh = 320
bus_kmh  = 120

[validation.thresholds.calendar]
min_feed_coverage_days       = 60
feed_expiration_warning_days = 14

[output]
show_progress = true
group_by_rule = true

La liste complète des sections et clés acceptées est sur référence / fichier de configuration.

Comportement en cas d’erreur

• Un fichier absent à n’importe quelle couche est ignoré silencieusement. Pas d’erreur, pas d’avertissement — il ne contribue juste pas au merge.
• Un fichier malformé (TOML cassé, clé inconnue) avorte avec code 2 et un message qui pointe le fichier et le token fautif. gapline refuse volontairement les clés inconnues pour qu’une faute de frappe sur un nom de section n’échappe pas à la validation.
• Une valeur sémantiquement invalide (vitesse négative, couverture calendrier nulle, seuil d’avertissement de transfert supérieur au max) avorte avec le même code et cite le champ précis.

Config error in ./gapline.toml: unknown field `validattion`, expected one of `default`, `validation`, `performance`, `output`, `batch`, `experimental`

Astuce

Lancez gapline validate --config ./gapline.toml avec la config que vous vous apprêtez à livrer. Si la validation démarre, la config est saine ; si elle avorte avec code 2, le message vous dit exactement quoi corriger.

Voir aussi

• Référence du fichier de configuration — chaque section, clé, type, défaut.
• Flags globaux — --config, --no-color, --threads.
• Valider des flux — comment la config est utilisée dans un pipeline réel.