cli: add container lint

[prestist]

Add an entrypoint that basically everyone can start
adding to their builds which performs some basic
static analysis for known problems.

---

(original description follows)

We know this does not fix #216 yet, we are working this in time-slots as a part of mobbing to address this. In the next update we plan on having the logic to check for one kernel complete. Then we can debate if we want the lint to be in this code base, or if we want it to be moved somewhere else.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[cgwalters]

Thanks for working on this!

Mostly nits.

[cgwalters]

Also it'd be great to have a test for this, which could be done in a variety of ways there's currently 3 distinct frameworks in use here (GHA, tmt, Prow+kola), which I'd like to take down to just the first two probably, except Prow is the most container-native which is what this test would be oriented towards. But basically building a derived image with two kernels and running the lint in it would make sense.

Another longer term thing to consider here is things like machine-readable output for lints; they're like compiler errors, with the same long term need for tooling that can do more to render than just scrape stdout.

[prestist]

Also it'd be great to have a test for this, which could be done in a variety of ways there's currently 3 distinct frameworks in use here (GHA, tmt, Prow+kola), which I'd like to take down to just the first two probably, except Prow is the most container-native which is what this test would be oriented towards. But basically building a derived image with two kernels and running the lint in it would make sense.

Thank you for that idea, we had not even gotten to the testing stage yet, I think this makes sense and we will look into doing this in our next mob session!

Another longer term thing to consider here is things like machine-readable output for lints; they're like compiler errors, with the same long term need for tooling that can do more to render than just scrape stdout.

Ah so similar to how the context.paths work in butane/ignition?

[cgwalters]

Ah so similar to how the context.paths work in butane/ignition?

I'm not sure, can you give an example? Or do you mean just how Ignition is inherently JSON?

My thought was like https://doc.rust-lang.org/rustc/json.html (could obviously be much, much simpler than that of course).

[cgwalters]

See #410 for another good lint.

[cgwalters]

Thanks for working on this! I think this is a good start; basically we can polish it up a bit and ship it I think.

[cgwalters]

#439 is perhaps another thing we could try to lint against. (That said I'm increasingly thinking we should just make everything else be usr_t.)

[cgwalters]

One thing that came up related to #128 is we found out that people are trying to do RUN podman pull <image> - this is another thing that we could at least detect at build time.

[jmarrero]

What about the land the initial kernel lint and then add the other lints on other PRs?

[prestist]

@jmarrero, I think that makes sense. I dont want to see this outstanding for much longer. That way we add value, and can add more as time allows. I need to rebase this thing before I add the doc's that colin wanted me to create though. After that the pr should be healthy.

[HuijingHei]

Agree with @jmarrero , make the original PR ready and let CI runs, can check if there is anything regression with the change.

[jmarrero]

@cgwalters how do you feel about this atm?

If you wanted to have the container subcommand I have an alternative here:

jmarrero@a0de33d

that runs via:

bootc container --lint instead of bootc build-lint

Is there one you think is better still, another option you prefer?

[cgwalters]

Thanks so much for working on this!

[cgwalters]

I went ahead and did some further updates here:

• Squashed the commits
• Moved the linting code into its own module
• Added targeted unit tests in that module
• Changed our own container build to use it just to dogfood
• Adjusted the documentation comments and ran cargo xtask man2markdown to generate manpages

WDYT?

[prestist]

I went ahead and did some further updates here:

* Squashed the commits

* Moved the linting code into its own module

* Added targeted unit tests in that module

* Changed our own container build to use it just to dogfood

* Adjusted the documentation comments and ran `cargo xtask man2markdown` to generate manpages

WDYT?

Im good to merge; Thank you for the assist! and all the help up to this point! LGTM.