Implement Annotation config types

[dmartmillan]

This pull request corresponds to Implement Annotation config types, implement Annotation configuration and its validator along with its tests. Relates to #64 issue.

In a way of mimicking openvariant/annotation/config_annotation.py and openvariant/annotation/annotation.py from Python-based implementation.

• Added src/annotation/config.rs, which defines the Annotation structure.
• Added src/annotation/validator.rs, including the main functions for parsing and validating the format of Annotation YAML files.
• Added the first Rust-based tests in src/tests/test_annotation/, which can be run with make test.
• Added Rust test execution to the GitHub workflow.
• Updated the Makefile to support Rust formatting and linting:
  • make fix: automatically fixes formatting and lint issues using clippy.
  • make check: verifies formatting and lint correctness.

For the moment, I didn't think about Warnings, only error. But they can be added.

If there are any tests missing, or if the validation is missing something, let me know. Also, I added tests inside src/ folder which I don't know if the best practice... because we have Python-based tests in the main folder as tests/

[Copilot]

Pull request overview

This PR introduces a Rust-native annotation configuration model (serde/YAML compatible) plus validation logic and unit tests, wiring the new annotation module into the crate and CI.

Changes:

• Added serde-compatible annotation config types (AnnotationType, AnnotationDelimiter, AnnotationFormat, and config structs) and re-exported them via src/annotation/mod.rs.
• Implemented YAML parse + validation entrypoints (parse_and_validate, validate_config) and added unit tests for config round-trips and validation scenarios.
• Updated build tooling and CI to run Rust tests, added stricter clippy settings, and introduced serde/yaml_serde dependencies.

Reviewed changes

Copilot reviewed 11 out of 12 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
src/annotation/config.rs	New serde/YAML config enums + structs for annotation configuration.
src/annotation/mod.rs	New module entrypoint and public re-exports for config + validator APIs.
src/annotation/validator.rs	New YAML parse + validation logic for annotation configs.
src/lib.rs	Exposes annotation module publicly and enables in-crate unit tests.
src/tests/mod.rs	Adds crate unit test module root.
src/tests/test_annotation/mod.rs	Adds annotation test module wiring.
src/tests/test_annotation/test_config.rs	Round-trip YAML serialization/deserialization tests for enums + config defaults.
src/tests/test_annotation/test_validator.rs	Tests for validator success and error cases.
Cargo.toml	Adds serde and yaml_serde dependencies needed for YAML config support.
Cargo.lock	Lockfile updates for new dependencies.
Makefile	Adds fmt/fix targets and makes clippy warnings fatal in lint/check.
.github/workflows/openvariant_tester.yml	Runs Rust tests in CI in addition to existing Python tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[FedericaBrando]

Thanks David for the work - very fun to review!

I have added some comments to be address, given the conversation we had on Slack.

Some other points:

• We should check if the fileMapping exists and fail fast if the file does not exist, also we should allow absolute paths, not only relatives to the yaml
• We should enforce the function field to start with lambda [var] : funct()
• One of the main pain points in openvariant as of now is the lack of error message when a field fails. Here we could be more verbose about what is failing during validation

Below I attach a git diff patch to be applied with suggested changes. Feel free to remove, change, or discard them if you think this is not what you were thinking.

Thanks!

pr-105-review.patch

[FedericaBrando]

I remember we added a feature where the delimiter could be detected automatically if the user did not set it - how this implementation include also the above mentioned case? Given that we are given as delimiter T or C and we default to T, if none is provided? #52

[FedericaBrando]

can't we use:

#[serde(rename_all = "UPPERCASE")]

[FedericaBrando]

Here we are using a struct, althugh serde does implement a tagged enum that maybe is useful in our case, and enforces the annotation field to have the correct entries.

#[serde(tag = "type", rename_all = "lowercase")]
enum AnnotationEntry {
    Static {
        field: String,
        value: yaml_serde::Value,
    },
    Internal {
        field: String,
        #[serde(default)]
        value: Option<String>,                
        field_source: <Vec<String>>,    
        #[serde(default)]
        function: Option<String>,             
    },
    Filename {
        field: String,
        #[serde(default)]
        function: Option<String>,
        #[serde(default)]
        regex: Option<String>,
    },
    Dirname {
        field: String,
        #[serde(default)]
        function: Option<String>,
        #[serde(default)]
        regex: Option<String>,
    },
    Plugin {
        field: String,
        plugin: String,                       
    },
    Mapping {
        field: String,
        field_source: Vec<String>,           
        field_mapping: String,
        file_mapping: String,
        field_value: String,
    },
}

[FedericaBrando]

function is not a field of Plugin, it is in fact a field of filename, dirname or internal right?

[FedericaBrando]

if we use serde tagged enums, then we could reduce the fields that are validated. For example only validate non duplicated field within a list, if the values are non-empty and all the things that you can't validate with structure.

[FedericaBrando]

Here couldn't we read it from a buffer directly?

https://docs.rs/yaml_serde/latest/yaml_serde/fn.from_reader.html