Enforce best practices for melange YAMLs

[imjasonh]

• checked-in packages shouldn't depend on packages.wolfi.dev/os or include its keyring; packages are fetched from that repo and depended on locally during the build
• every melange YAML should have a corresponding entry in Makefile (would have caught fix bugs found while linting #84)
• maybe harder to catch without involving dag: no duplicate package or subpackage names (would have caught fix erroneus libice-static definitions #85)
• less importantly, consistently format YAML (mostly to avoid formatting arguments)
• more generally, melange could fail if it encounters an unknown field -- this would have caught the epcho bug fixed in fix bugs found while linting #84

These checks should be enforced at CI time to prevent bugs from being committed.

This is complicated somewhat by the fact that melange YAML files aren't actually parseable YAML files, they're templates that get Go-templated into parseable YAML. Maybe we could templateize them then YAML-format them, or something else smart we haven't thought of yet.

[kaniini]

I have some thoughts based on updating wolfi-secdb, which caught a few things in #81. I'm probably going to add a melange lint action, which can check some of these things, and then we can extend that into a wolfi-specific linting package.

[Dentrax]

I'm probably going to add a melange lint action

Any ongoing work on this? I'd be nice to have a tracking issue for this in the melange side. If you split into smaller tasks, we are ready to help! @developer-guy

Additional to @.imjasonh ideas, here are some other ideas:

• smoke test first: check if given file a valid build.Configuration struct
• check if copytight.license is correct (external api call needed to check LICENSE file, handling just GitHub would be fine in the first place)
• traverse all target-architecture, ensure melange have a support for each
• enforce package.version in semantic-versioning format
• pipeline.with.uri is correct URI format (not sure how to handle ${{ foo }} stuff)
• pipeline.with.expected-sha256 is correct sha256 format (do same for other algorithms)
• version pinned URIs ¹ (rather than master, main, etc.)

Footnotes

1. https://github.com/wolfi-dev/os/pull/163?notification_referrer_id=MDE4Ok5vdGlmaWNhdGlvblRocmVhZDUwMDI5OTUxNjY6MTY0OTM3NTE%3D#discussion_r1039790007 ↩

[developer-guy]

It should be a separate command in the wolfictl CLI

[kaniini]

@Dentrax says he wants to work on this, so assigning it to him!

[rawlingsj]

@Dentrax have you started working on this? I've got a need for a CI check so am thinking it best live in wolfictl lint. If I make a start perhaps you can add extra lints to it once available?

[Dentrax]

Actual I already started on a branch to add a new lint subcommand to wolfictl, then couldn't find a proper time to implement lint engine. We'll (@developer-guy) get into it this week. We may request a help from you if we get stuck somewhere. Deal? 😇

[rawlingsj]

Do you want to PR what you have? Even if it's just the structure and then we can both work on adding different linting together?

Or maybe as soon as you do have the initial structure create a PR and we can add the different lints as followups?

[Dentrax]

Oh, sure definitely! We want to submit an initial PR as soon as we have some bare-minimum. (Which currently I don't have a one) So that we can start to work on adding different lints collaboratively!

[Dentrax]

Here is, we (@developer-guy) submit the initial PR for implementing the lint subcommand! 🥳 wolfi-dev/wolfictl#2 (Waiting your feedback.)