4 releases

0.2.2 May 30, 2023
0.2.1 Jul 25, 2022
0.2.0 Feb 28, 2022
0.1.0 Nov 18, 2019

#2421 in Parser implementations

Download history 41/week @ 2024-03-12 22/week @ 2024-03-19 16/week @ 2024-03-26 64/week @ 2024-04-02 19/week @ 2024-04-09 27/week @ 2024-04-16 39/week @ 2024-04-23 43/week @ 2024-04-30 24/week @ 2024-05-07 24/week @ 2024-05-14 38/week @ 2024-05-21 26/week @ 2024-05-28 30/week @ 2024-06-04 35/week @ 2024-06-11 26/week @ 2024-06-18 25/week @ 2024-06-25

121 downloads per month
Used in git-checks

MIT/Apache

160KB
4K SLoC

Configurations for Git checks

When using git checks, it is often useful to store what checks to read within configuration files. This crate allows for checks to also offer support for reading structures from configuration files and turning them into instances of checks. Another point is that adding another check to a crate requires consumers to update to consume that new check. Here, the [inventory][inventory] is used to create a global registry that consuming applications can use to automatically discover new checks added to the application from anywhere.

Caveats

One downside of this is that there is then one "blessed" serialization for a check. This crate aims to not preclude such uses and as such, checks themselves should generally not implement Deserialize. Instead, a separate structure should be created which then creates the check.

Example

struct MyCheck {
    field1: bool,
}

impl Check for MyCheck {
    // implementation
}

struct MyCheckConfig {
    #[serde(default)]
    field1: bool
}

impl IntoCheck for MyCheckConfig {
    type Check = MyCheck;

    fn into_check(self) -> Self::Check {
        MyCheck {
            field1: self.field1,
        }
    }
}

register_checks! {
    MyCheckConfig {
        "name_of_check" => CommitCheckConfig,
    }
}

Dependencies

~7–19MB
~254K SLoC