From 48db9b438a1b9ec8171fe4957ec92a6fb7ca3e86 Mon Sep 17 00:00:00 2001 From: user Date: Fri, 4 Sep 2026 12:08:54 +0000 Subject: [PATCH] test(lint-once): read docker image/builder build as builds too MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `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 | 53 +++++++++++++++++--------------- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/test/packaging/lint-once.test.ts b/test/packaging/lint-once.test.ts index ce4198b..2813716 100644 --- a/test/packaging/lint-once.test.ts +++ b/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 .` emitted no edge at all, not // even the default one. A recognised build resolves to the file named by // `-f`, `-f=`, `-f` 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[] = [];