Add a pre-commit for validating zarf schema

[YrrepNoj]

Description

Add a pre-commit hook that will validate that the ZarfInitConfig ./zarf.yaml confirms to the schema defined at ./zarf.schema.json. This will help prevent issues where developers update the init config without updating the schema.

Related Issue(s)

Fixes #216

[jeff-mccoy]

Lgtm, just tested and it rejected as expected.

[YrrepNoj]

This is the result of the pre-commit hook if you change the zarf.yaml without changing the schema definition.

[jeff-mccoy]

We will need to look into this some more. This only checks the zarf.yaml for init packages and isn't fully verifying that the generated schema actually is correct. Would it be simpler to just run zarf tools config-schema > zarf.schema.json in a pre-commit step?

[RothAndrew]

We will need to look into this some more. This only checks the zarf.yaml for init packages and isn't fully verifying that the generated schema actually is correct. Would it be simpler to just run zarf tools config-schema > zarf.schema.json in a pre-commit step?

It's not quite this simple, but yes, it should be along these lines. pre-commit is already smart enough to know that a changed file means a failed hook.

[RothAndrew]

I would like to merge this PR, as what it is doing is still valuable, just without closing #216.

[RothAndrew]

Though, it would be better to have the hook check all zarf.yaml files that get changed in the repo, rather than just the root one. I haven't looked closely at the hook's capabilities, but if it does what I think it should we can change the work here to run the hook an all files named zarf.yaml

[YrrepNoj]

This hook will run against any file named zarf.yaml that has been staged for commit

Here it's running against one of the example packages zarf.yaml

.

[RothAndrew]

Cool, then yeah, I'd like to merge this, just without closing #216

[YrrepNoj]

Would it be simpler to just run zarf tools config-schema > zarf.schema.json in a pre-commit step?

If we're going to do something like that I would rather do it in an automated pipeline instead of a pre-commit hook.

1. I don't want the pre-commit to be dependent on having the CLI built and building it in the hook would be too slow which seems like a lot of friction.
2. We could probably do it without the zarf CLI but that would require dependencies to be manually installed which is also too much friction IMO.

[jeff-mccoy]

It doesn't need to "be built", it could be go run cli/main.go tools. But 🤷

[RothAndrew]

The pre-commit hooks don't have to be run locally, though once we turn on verification of them in the pipeline it will be a lot easier to run them locally then get the feedback loop on what still needs to be fixed from the pipeline.

My vision for the pipeline is that it will run pre-commit run -a which will fail if any of the hooks fail, which would easily and automatically get us linting, checking for secrets, code style (after we add a styler similar to how Prettier or Black work), and other great automated checks.

[RothAndrew]

Doing so will require certain CLI tools to be installed on the developer's machine, such as golangci-lint.

[YrrepNoj]

pre-commit hook now verifies the zarf-schema is up-to-date if the cli/types/types.go file is ever updated. It also still verifies any modified zarf.yaml conforms to the schema.