Add additional warnings for lint rules

[daghack]

We should define a set of rules for evaluating a good or bad Dockerfile. Create a method for evaluating the Dockerfile to ensure obvious issues are highlighted to the user.

This PR adds 3 additional lint warnings for the Dockerfile frontend:

• lowercased stage names
• lowercased command flag values
• consistently cased commands

These rules are definitely not the comprehensive list of linting warnings we should add, but instead represent an initial set, with more to come in additional PRs moving forward! 😄

( This PR existed in a similar, previous PR #4751, but only implements the warnings. The additional --print=lint functionality will come in its own PR. 😄 )

[thaJeztah]

Some other possible ideas for linting;

• deprecate Dockerfile legacy 'ENV name value' syntax docker/cli#2743
• relates to dockerfile: allow multiple values for ARG #1692 (comment)

Perhaps also worth checking for;

• ARG HTTP_PROXY and other proxy ones (the _proxy ones are special cases to be always supported)
• ENV HTTP_PROXY usually a big "nope" unless you want the image to be only functional in your environment with that proxy.
• maybe too strict (?) should we have something to point users to the special "godoc-like" format of comments to document stages? dockerfile: parse comments associated with args and stages #1693
• comments not starting at position 0
• a popular one from the past; [Builder] Warn on empty continuation lines moby#33719

[thaJeztah]

Oh! And if we consider "best practices", we could consider that a Dockerfile should start with a # syntax☺️

[daghack]

Those are great suggestions! There's quite a few linting rules that we want to add moving forward, these three are meant to be just the initial set, with other linting rules being introduced in future PRs! I've updated the initial comment to note that, because this is definitely just a first stepping stone! :D

[thaJeztah]

For sure! I saw your PR and was interested; consider my comment purely as "hey, these might be interesting to add as well!"

[colinhemmings]

These are great, thanks @thaJeztah. I will send out a proposal shortly to capture more input on this.

[daghack]

[daghack]

I'm not a super fan of the lack of any real context in the inline, and think that perhaps having the output in those cases include filename+linenumbers, but when I tried this it came at the cost of the --debug info looking pretty cluttered and having redundant information between the Short and the additional printed information.

@tonistiigi Thoughts/Preferences?

[tonistiigi]

@daghack We can improve the short message so that instead of constant text it says "prefix: FOObar casing is inconsistent with the rest of the Dockerfile (app.Dockerfile:12)" or smth similar.

[daghack]

Ended up being a bit of refactoring to get cleaner output, and updated to address @tonistiigi feedback!
Screenshots of updated output (the first being what displays inline during the build, the with the additional context displayed via the docker --debug flag.

[daghack]

Incorporated lots of feedback by @tonistiigi, now looking for a review! :)

[daghack]

@tonistiigi Ping :)

[daghack]

Getting there, slowly but surely!

[daghack]

@tonistiigi 🎉 No write access, can I get a merge too? 😮 Ty!