Introduce a zarf prepare lint command

[Racer159]

Is your feature request related to a problem? Please describe.

We should introduce a zarf prepare lint command that will look at a zarf.yaml file and then error or warn when a zarf.yaml is out of spec with best practices.

Describe the solution you'd like

• Given I have a zarf.yaml that is not following best practices
• When I run zarf prepare lint on that file
• Then I receive a list of notes, warnings or errors according to the following:

• error: invalid package schema
• warning: flagged package warning (i.e. from p.warnings / deprecations)
• warning: unpinned dependencies (repos or images without a tagged reference)
• warning: files without pinned shasums
• note: variables, packages, actions and components without descriptions

Describe alternatives you've considered

We could publish these as docs, but having them coded into a command allows them to be run in CI and updated without people needing to go back and read a docs page.

Additional context

This will help package development scale and push the Zarf community's view of what makes a "good" Zarf package.

[Racer159]

It may be worth it to yamllint downstream manifests and values files that are directly provided to Zarf as well https://kubernetes.slack.com/archives/C03B6BJAUJ3/p1697579246332669?thread_ts=1683149646.315369&cid=C03B6BJAUJ3

[AustinAbro321]

I would also like to give the user the line number in the future

[AustinAbro321]

For checking unpinned repos I'm leaning towards just checking if the repo doesn't contain "@" or "/-/". Could result in some false negatives since repos can have "@" in the name. This should cover github, dev.azure, and gitlab repos. Any source control sites popular among our users that I should take a look at @Racer159? Those would likely have false positives if they urls aren't built like github / gitlab

[AustinAbro321]

We may want either run every combination of architecture or pass in architectures from lint

[AustinAbro321]

We should warn if variables are not being used anywhere

[AustinAbro321]

We can also use variable defaults / set values we can get to make sure that the downstream mainfests / helmcharts are valid yaml

[AustinAbro321]

I would like to allow yaml extensions in the schema. They will work currently but give a schema error https://docs.docker.com/compose/compose-file/11-extension/.

This was resolved by: #2217

[AustinAbro321]

verify that the zarf-config.yaml / toml / ini / json has at least package.deploy or package.create

[Racer159]

Tying this to this since this is the other side of variables linting: #2096

[AustinAbro321]

Command has been introduced. Putting further lints in the other issues. Moving flagged package warning (i.e. from p.warnings / deprecations) will go in #2485