#git #code-review

git-checks-config

Configuration parsing for checks

3 unstable releases

0.2.1 Jul 25, 2022
0.2.0 Feb 28, 2022
0.1.0 Nov 18, 2019

#154 in Configuration

Download history 20/week @ 2022-10-07 17/week @ 2022-10-14 18/week @ 2022-10-21 21/week @ 2022-10-28 44/week @ 2022-11-04 19/week @ 2022-11-11 21/week @ 2022-11-18 17/week @ 2022-11-25 21/week @ 2022-12-02 27/week @ 2022-12-09 25/week @ 2022-12-16 20/week @ 2022-12-23 16/week @ 2022-12-30 18/week @ 2023-01-06 21/week @ 2023-01-13 22/week @ 2023-01-20

80 downloads per month
Used in git-checks

MIT/Apache

17KB
338 lines


lib.rs:

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

~4–5.5MB
~115K SLoC