test(lint-once): read docker image/builder build as builds too

`docker image build` and `docker builder build` are management-command
spellings of the same build, take the same -f, and were emitting no edge at
all — the same shape as the buildx miss.

test/packaging/lint-once.test.ts

@@ -39,13 +39,14 @@
 // one pass over literals, so a value that itself names another variable, a
 // value built by a make function (`$(shell ...)`, `$(addprefix ...)`), and the
 // body of a `define`/`endef` block are not expanded and not followed. A
-// build is recognised as `docker build`, as `docker buildx build`, and as
-// either of those reached through global flags standing between the command
-// and the subcommand (`docker --context ci build`, `docker -H tcp://h:2375
-// buildx build`), a flag's separate argument being stepped over; `docker
-// compose build` is deliberately not, since it builds services out of a
-// compose file this walk does not read, and neither is any other non-flag word
-// in that position. Matching only a literal `docker build` was worse than a
+// build is recognised as `docker build`, as its three management-command
+// spellings (`docker buildx build`, `docker image build`, `docker builder
+// build`), and as any of those reached through global flags standing between
+// the command and the subcommand (`docker --context ci build`, `docker -H
+// tcp://h:2375 buildx build`), a flag's separate argument being stepped over;
+// `docker compose build` is deliberately not, since it builds services out of
+// a compose file this walk does not read, and neither is any other non-flag
+// word in that position. Matching only a literal `docker build` was worse than a
 // wrong file: `docker buildx build -f <file> .` emitted no edge at all, not
 // even the default one. A recognised build resolves to the file named by
 // `-f`, `-f=`, `-f<file>` with the value attached to the flag, `--file` or
@@ -423,25 +424,29 @@ const commandsOf = (node: string): string[] => {
 
 // Which invocation shapes read as a build, and which do not.
 //
-// RECOGNISED: `docker build`, `docker buildx build`, and either of those
-// reached through global flags between the command and the subcommand —
-// `docker --context ci build`, `docker -H tcp://host:2375 build`,
-// `docker --debug buildx build`. A global flag's separate argument is stepped
-// over (`--context ci`), and an `=`-joined one is a single token
-// (`--context=ci`). `docker buildx build` was the concrete miss: `\bdocker\s+
-// build\b` cannot reach across `buildx`, so `docker buildx build -f
-// Dockerfile.extra .` in script/cibuild emitted no edge at all — not even the
-// default `Dockerfile` one — and a tree running prettier twice reported green.
+// RECOGNISED: `docker build`, the three management-command spellings of the
+// same thing — `docker buildx build`, `docker image build`, `docker builder
+// build` — and any of those reached through global flags standing between the
+// command and the subcommand: `docker --context ci build`, `docker -H
+// tcp://host:2375 build`, `docker --debug buildx build`. A global flag's
+// separate argument is stepped over (`--context ci`), and an `=`-joined one is
+// a single token (`--context=ci`). All of these read `-f` the same way and
+// build the Dockerfile it names, so all of them are edges.
 //
-// NOT RECOGNISED, deliberately: `docker compose build`, which builds compose
-// services out of a compose file this parser does not read, so resolving it
-// against a Dockerfile path would be a wrong answer rather than a missing one;
-// `docker builder build`; and any spelling that puts a non-flag word other
-// than `buildx` between `docker` and `build`. Only `-`-prefixed tokens (plus
-// their arguments) and the single literal `buildx` are stepped over, so
-// `docker run -f build` and `docker image build`-style shapes do not match.
+// `docker buildx build` was the concrete miss: `\bdocker\s+build\b` cannot
+// reach across `buildx`, so `docker buildx build -f Dockerfile.extra .` in
+// script/cibuild emitted no edge at all — not even the default `Dockerfile`
+// one, which the old file-flag bug at least still produced — and a tree
+// running prettier twice reported green.
+//
+// NOT RECOGNISED, deliberately: `docker compose build`, which builds services
+// named in a compose file this parser does not read, so resolving it against a
+// Dockerfile path would be a wrong answer rather than a missing one. Only
+// `-`-prefixed tokens (plus their arguments) and those three literal
+// subcommand words are stepped over, so no other non-flag word between
+// `docker` and `build` matches, and `docker run -f build` is not a build.
 const DOCKER_BUILD =
-    /\bdocker(?:\s+-{1,2}[A-Za-z][\w-]*(?:=\S+)?(?:\s+[^-\s]\S*)?)*(?:\s+buildx)?\s+build\b/g;
+    /\bdocker(?:\s+-{1,2}[A-Za-z][\w-]*(?:=\S+)?(?:\s+[^-\s]\S*)?)*(?:\s+(?:buildx|image|builder))?\s+build\b/g;
 
 const edgesOf = (line: string): string[] => {
     const edges: string[] = [];