frontend: command casing rule check after parsing the ast

[daghack]

addresses @tonistiigi comments in #5240

Currently we're checking the AST for command violations, but typically it is more convenient and correct for these checks to happen at the instruction level. This updates the consistent command casing check to occur after the AST is parsed out into instructions.

[tonistiigi]

We need test for this as well that covers #5240

[daghack]

We need test for this as well that covers #5240

Added!

[tonistiigi]

fyi @jedevc

[jedevc]

SGTM, but if this is a common typo, potentially there should be a more dedicated lint message.

Confused about dash in the example

[thaJeztah]

Confused about dash in the example

This was a mistake on my hand in the linked ticket, and the - shouldn't have been there (I blindly wrote it out of habit); see #5240 (comment)

So in this case, there's 3 "commands";

• RUN -<<'EOT' - which will produce an error
• env - which (at least before this PR) produces both a warning (lowercase) and an error
• EOT - invalid instruction, but it looks like we bail out before reaching that

i.e., this currently (before this PR) produces;

docker build -<<'EOF'
FROM alpine
RUN -<<'EOT'
env
EOT
EOF

[+] Building 0.1s (1/1) FINISHED                                                                                        docker:desktop-linux
 => [internal] load build definition from Dockerfile                                                                                    0.0s
 => => transferring dockerfile: 70B                                                                                                     0.0s
 => WARN: ConsistentInstructionCasing: Command 'env' should match the case of the command majority (uppercase) (line 3)                 0.0s

 1 warning found (use docker --debug to expand):
 - ConsistentInstructionCasing: Command 'env' should match the case of the command majority (uppercase) (line 3)
Dockerfile:3
--------------------
   1 |     FROM alpine
   2 |     RUN -<<'EOT'
   3 | >>> env
   4 |     EOT
   5 |
--------------------
ERROR: failed to solve: dockerfile parse error on line 3: ENV requires at least one argument

View build details: docker-desktop://dashboard/build/desktop-linux/desktop-linux/q4mv7723jfvmni1dvj3ptkji2

As the Dockerfile is invalid, to some extent, I'd expect this to;

• skip printing all linting warnings; they're not relevant if the dockerfile is invalid
• if possible, detect (all?) invalid syntax issues (i.e. both env as invalid and EOT being an invalid command)
• ☝️ 🤔 that could become noisy though, because the heredoc may contain many lines, all of which would now be considered an "invalid dockerfile instruction"
• 👉 so, yes, perhaps still fail early, but if possible, have a useful "did you mean X?" for the invalid here-doc 🤔

[daghack]

Yeah, I was pretty much just replicating the original failure mode in the tests. That being said, is a fix so that we don't get erroneous rule checks from the contents of the heredoc, and doesn't need to reproduce the dockerfile error in the integration test (which I think the point @tonistiigi was making).

[daghack]

@tonistiigi Updated the test to not be based on the heredoc typo. :)

[thompson-shaun]

Do we still want to merge this based on the discussions in #5240? @daghack

[daghack]

Do we still want to merge this based on the discussions in #5240? @daghack

I'm inclined, because I generally think removing checks from the AST stage is a net benefit, even if it's not a fix for the issue where it came up. I'll happily defer to @tonistiigi, though.