Contribuer

Les issues et pull requests sont les bienvenus sur GitHub. Cette page couvre la structure du workspace, la compilation et les tests en local, les conventions du code, et les étapes précises pour ajouter une nouvelle règle de validation.

Structure du workspace

gapline est un workspace Cargo à deux crates :

Crate	Chemin	Rôle
gapline-core	core/	Parsing de flux, moteur de validation, primitives CRUD, index d’intégrité, règles.
gapline	cli/	Le binaire CLI — parsing d’arguments, rendu de sortie, chargeur de config, runner .gl.

gapline/
├── Cargo.toml        # Manifest workspace.
├── LICENSE
├── README.md
├── core/
│   ├── src/
│   ├── benches/
│   └── tests/
└── cli/
    ├── src/
    ├── CHANGELOG.md
    └── tests/

Prérequis

• Rust 1.70 ou ultérieur. Installez avec rustup.
• Une toolchain C (pour les dépendances natives du crate zip).

Optionnels mais recommandés :

• cargo-nextest pour des runs de tests plus rapides.
• prek pour les hooks pre-commit (un prek.toml est committé).

Compiler

Depuis la racine du workspace :

cargo build --workspace
cargo build --workspace --release

Le binaire CLI arrive dans target/release/gapline.

Tester

Lancer la suite complète :

cargo test --workspace

Ou avec nextest :

cargo nextest run --workspace

Les tests unitaires vivent dans des modules #[cfg(test)] à côté du code qu’ils exercent. Les tests d’intégration sont sous <crate>/tests/. Le crate core a des benchmarks sous core/benches/ :

cargo bench -p gapline-core

Lint

clippy est configuré pour échouer sur les warnings. Avant de soumettre une PR, passez les deux checks équivalents à la CI :

cargo fmt --all -- --check
cargo clippy --workspace -- -D warnings

Conventions de commit

Les sujets de commit suivent les Conventional Commits (visibles dans le changelog CLI) :

• feat: add speed_validation rule
• fix(cli): correct --feed help text grammar
• perf(core): drop double alloc in required_id/optional_id

Les catégories utilisées dans le changelog sont feat, fix, perf, feat! (breaking).

Ajouter une règle de validation

1. Choisir un stage. Les règles vivent sous core/src/validation/<stage>/. Les stages existants : file_structure, csv_formatting, field_definition, field_type, foreign_key, primary_key, schedule_time_validation, best_practices, third_party.

2. Implémenter la règle. Chaque règle implémente un trait de validation dans son module de stage. Retournez des ValidationError avec rule_id, severity, message, et autant de contexte (file_name, line_number, field_name, value) que possible.

3. Enregistrer la règle. Ajoutez-la au registre dans core/src/validation/rules.rs pour que gapline rules list la prenne.

4. Tester. Un test unitaire positif et négatif dans le même module. Un test d’intégration sous core/tests/ si la règle couvre plusieurs fichiers.

5. Documenter la règle. L’ID sera automatiquement inclus dans le catalogue après génération du JSON.

Ajouter un flag CLI

1. Ajoutez le champ à la variante correspondante de Commands dans cli/src/cli/parser.rs.
2. Raccordez-le au runner de la commande sous cli/src/cli/commands/.
3. Mettez à jour la page de référence sous doc-site/src/content/docs/reference/cli/.
4. Si le flag a un équivalent dans gapline.toml, ajoutez la clé à core/src/config.rs et mettez à jour doc-site/src/content/docs/reference/configuration-file.md.

Ajouter une directive .gl

Le runner .gl est dans cli/src/cli/runner/. Les directives sont parsées dans parser.rs et dispatchées dans executor.rs. Pour une nouvelle directive :

1. Étendre DirectiveKind dans parser.rs.
2. Ajouter la fonction de parse.
3. Ajouter la branche de l’executor.
4. Documenter la directive sur syntaxe .gl.

Code of conduct

Traitez chaque contributeur avec respect. Le repo suit le Contributor Covenant : soyez gentil, clair, et restez sur le sujet.

Voir aussi

• Projet sur GitHub — issues, PRs, releases.
• Changelog — ce qui a atterri dans chaque release.
• Licence — termes de licence pour les contributions.