diff --git a/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md b/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md index 665d97f936..b117bf6e57 100644 --- a/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md +++ b/_vendor/github.com/moby/buildkit/docs/buildkitd.toml.md @@ -136,4 +136,25 @@ insecure-entitlements = [ "network.host", "security.insecure" ] # optionally mirror configuration can be done by defining it as a registry. [registry."yourmirror.local:5000"] http = true + +# Frontend control +[frontend."dockerfile.v0"] + enabled = true + +[frontend."gateway.v0"] + enabled = true + + # If allowedRepositories is empty, all gateway sources are allowed. + # Otherwise, only the listed repositories are allowed as a gateway source. + # + # NOTE: Only the repository name (without tag) is compared. + # + # Example: + # allowedRepositories = [ "docker-registry.wikimedia.org/repos/releng/blubber/buildkit" ] + allowedRepositories = [] + +[system] + # how often buildkit scans for changes in the supported emulated platforms + platformsCacheMaxAge = "1h" + ``` diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md index 1b288f8889..d49db127bb 100644 --- a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/reference.md @@ -1520,7 +1520,7 @@ not translate between Linux and Windows, the use of `/etc/passwd` and `/etc/grou translating user and group names to IDs restricts this feature to only be viable for Linux OS-based containers. -All files and directories copied from the build context are created with a UID and GID of 0.unless the +All files and directories copied from the build context are created with a UID and GID of `0` unless the optional `--chown` flag specifies a given username, groupname, or UID/GID combination to request specific ownership of the copied content. The format of the `--chown` flag allows for either username and groupname strings diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md new file mode 100644 index 0000000000..9e5b091ba0 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/_index.md @@ -0,0 +1,88 @@ +--- +title: Build checks +description: | + BuildKit has built-in support for analyzing your build configuration based on + a set of pre-defined rules for enforcing Dockerfile and building best + practices. +keywords: buildkit, linting, dockerfile, frontend, rules +--- + +BuildKit has built-in support for analyzing your build configuration based on a +set of pre-defined rules for enforcing Dockerfile and building best practices. +Adhering to these rules helps avoid errors and ensures good readability of your +Dockerfile. + +Checks run as a build invocation, but instead of producing a build output, it +performs a series of checks to validate that your build doesn't violate any of +the rules. To run a check, use the `--check` flag: + +```console +$ docker build --check . +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDescription
StageNameCasingStage names should be lowercase
FromAsCasingThe 'as' keyword should match the case of the 'from' keyword
NoEmptyContinuationsEmpty continuation lines will become errors in a future release
ConsistentInstructionCasingInstructions should be in consistent casing (all lower or all upper)
FileConsistentCommandCasingAll commands within the Dockerfile should use the same casing (either upper or lower)
DuplicateStageNameStage names should be unique
ReservedStageNameReserved words should not be used as stage names
JSONArgsRecommendedJSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals
MaintainerDeprecatedThe MAINTAINER instruction is deprecated, use a label instead to define an image author
UndefinedArgInFromFROM command must use declared ARGs
WorkdirRelativePathRelative workdir without an absolute workdir declared within the build can have unexpected results if the base image changes
UndefinedVarVariables should be defined before their use
MultipleInstructionsDisallowedMultiple instructions of the same type should not be used in the same stage
LegacyKeyValueFormatLegacy key/value format with whitespace separator should not be used
diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md new file mode 100644 index 0000000000..f2432bede2 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/consistent-instruction-casing.md @@ -0,0 +1,45 @@ +--- +title: ConsistentInstructionCasing +description: Instructions should be in consistent casing (all lower or all upper) +aliases: + - /go/dockerfile/rule/consistent-instruction-casing/ +--- + +## Output + +```text +Command 'EntryPoint' should be consistently cased +``` + +## Description + +Instruction keywords should use consistent casing (all lowercase or all +uppercase). Using a case that mixes uppercase and lowercase, such as +`PascalCase` or `snakeCase`, letters result in poor readability. + +## Examples + +❌ Bad: don't mix uppercase and lowercase. + +```dockerfile +From alpine +Run echo hello > /greeting.txt +EntRYpOiNT ["cat", "/greeting.txt"] +``` + +✅ Good: all uppercase. + +```dockerfile +FROM alpine +RUN echo hello > /greeting.txt +ENTRYPOINT ["cat", "/greeting.txt"] +``` + +✅ Good: all lowercase. + +```dockerfile +from alpine +run echo hello > /greeting.txt +entrypoint ["cat", "/greeting.txt"] +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md new file mode 100644 index 0000000000..67fe4da8c1 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/duplicate-stage-name.md @@ -0,0 +1,38 @@ +--- +title: DuplicateStageName +description: Stage names should be unique +aliases: + - /go/dockerfile/rule/duplicate-stage-name/ +--- + +## Output + +```text +Duplicate stage name 'foo-base', stage names should be unique +``` + +## Description + +Defining multiple stages with the same name results in an error because the +builder is unable to uniquely resolve the stage name reference. + +## Examples + +❌ Bad: `builder` is declared as a stage name twice. + +```dockerfile +FROM debian:latest AS builder +RUN apt-get update; apt-get install -y curl + +FROM golang:latest AS builder +``` + +✅ Good: stages have unique names. + +```dockerfile +FROM debian:latest AS deb-builder +RUN apt-get update; apt-get install -y curl + +FROM golang:latest AS go-builder +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/file-consistent-command-casing.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/file-consistent-command-casing.md new file mode 100644 index 0000000000..7d6188b1f5 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/file-consistent-command-casing.md @@ -0,0 +1,61 @@ +--- +title: FileConsistentCommandCasing +description: All commands within the Dockerfile should use the same casing (either upper or lower) +aliases: + - /go/dockerfile/rule/file-consistent-command-casing/ +--- + +## Output + +Example warning: + +```text +Command 'foo' should match the case of the command majority (uppercase) +``` + +## Description + +Instructions within a Dockerfile should have consistent casing through out the +entire files. Instructions are not case-sensitive, but the convention is to use +uppercase for instruction keywords to make it easier to distinguish keywords +from arguments. + +Whether you prefer instructions to be uppercase or lowercase, you should make +sure you use consistent casing to help improve readability of the Dockerfile. + +## Examples + +❌ Bad: mixed uppercase and lowercase. + +```dockerfile +FROM alpine:latest AS builder +run apk --no-cache add build-base + +FROM builder AS build1 +copy source1.cpp source.cpp +``` + +✅ Good: all uppercase. + +```dockerfile +FROM alpine:latest AS builder +RUN apk --no-cache add build-base + +FROM builder AS build1 +COPY source1.cpp source.cpp +``` + +✅ Good: all lowercase. + +```dockerfile +from alpine:latest as builder +run apk --no-cache add build-base + +from builder as build1 +copy source1.cpp source.cpp +``` + +## Related errors + +- [`FromAsCasing`](./from-as-casing.md) + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md new file mode 100644 index 0000000000..30431e4d8d --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/from-as-casing.md @@ -0,0 +1,44 @@ +--- +title: FromAsCasing +description: The 'as' keyword should match the case of the 'from' keyword +aliases: + - /go/dockerfile/rule/from-as-casing/ +--- + +## Output + +```text +'as' and 'FROM' keywords' casing do not match +``` + +## Description + +While Dockerfile keywords can be either uppercase or lowercase, mixing case +styles is not recommended for readability. This rule reports violations where +mixed case style occurs for a `FROM` instruction with an `AS` keyword declaring +a stage name. + +## Examples + +❌ Bad: `FROM` is uppercase, `AS` is lowercase. + +```dockerfile +FROM debian:latest as builder +``` + +✅ Good: `FROM` and `AS` are both uppercase + +```dockerfile +FROM debian:latest AS deb-builder +``` + +✅ Good: `FROM` and `AS` are both lowercase. + +```dockerfile +from debian:latest as deb-builder +``` + +## Related errors + +- [`FileConsistenCommandCasing`](./file-consistent-command-casing.md) + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md new file mode 100644 index 0000000000..0d69b2a67c --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/json-args-recommended.md @@ -0,0 +1,66 @@ +--- +title: JSONArgsRecommended +description: JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals +aliases: + - /go/dockerfile/rule/json-args-recommended/ +--- + +## Output + +```text +JSON arguments recommended for ENTRYPOINT/CMD to prevent unintended behavior related to OS signals +``` + +## Description + +`ENTRYPOINT` and `CMD` instructions both support two different syntaxes for +arguments: + +- Shell form: `CMD my-cmd start` +- Exec form: `CMD ["my-cmd", "start"]` + +When you use shell form, the executable runs as a child process to a shell, +which doesn't pass signals. This means that the program running in the +container can't detect OS signals like `SIGTERM` and `SIGKILL` and respond to +them correctly. + +## Examples + +❌ Bad: the `ENTRYPOINT` command doesn't receive OS signals. + +```dockerfile +FROM alpine +ENTRYPOINT my-program start +# entrypoint becomes: /bin/sh -c my-program start +``` + +To make sure the executable can receive OS signals, use the exec form for `CMD` +and `ENTRYPOINT`, which lets you run the executable as the main process (`PID +1`) in the container, avoiding a shell parent process. + +✅ Good: the `ENTRYPOINT` receives OS signals. + +```dockerfile +FROM alpine +ENTRYPOINT ["my-program", "start"] +# entrypoint becomes: my-program start +``` + +Note that running programs as PID 1 means the program now has the special +responsibilities and behaviors associated with PID 1 in Linux, such as reaping +child processes. + +Alternatively, if you want to ignore this lint rule because you do want your +executable to be invoked via a shell, you can use the +[`SHELL`](https://docs.docker.com/reference/dockerfile.md#shell) Dockerfile +instruction to explicitly specify a shell to use. + +✅ Good: shell is explicitly defined. + +```dockerfile +FROM alpine +RUN apk add bash +SHELL ["/bin/bash", "-c"] +ENTRYPOINT echo "hello world" +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md new file mode 100644 index 0000000000..32003b399c --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/legacy-key-value-format.md @@ -0,0 +1,38 @@ +--- +title: LegacyKeyValueFormat +description: Legacy key/value format with whitespace separator should not be used +aliases: + - /go/dockerfile/rule/legacy-key-value-format/ +--- + +## Output + +```text +"ENV key=value" should be used instead of legacy "ENV key value" format +``` + +## Description + +The correct format for declaring environment variables and build arguments in a +Dockerfile is `ENV key=value` and `ARG key=value`, where the variable name +(`key`) and value (`value`) are separated by an equals sign (`=`). +Historically, Dockerfiles have also supported a space separator between the key +and the value (for example, `ARG key value`). This legacy format is deprecated, +and you should only use the format with the equals sign. + +## Examples + +❌ Bad: using a space separator for variable key and value. + +```dockerfile +FROM alpine +ARG foo bar +``` + +✅ Good: use an equals sign to separate key and value. + +```dockerfile +FROM alpine +ARG foo=bar +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md new file mode 100644 index 0000000000..c777a17d34 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/maintainer-deprecated.md @@ -0,0 +1,33 @@ +--- +title: MaintainerDeprecated +description: The MAINTAINER instruction is deprecated, use a label instead to define an image author +aliases: + - /go/dockerfile/rule/maintainer-deprecated/ +--- + +## Output + +```text +MAINTAINER instruction is deprecated in favor of using label +``` + +## Description + +The `MAINTAINER` instruction, used historically for specifying the author of +the Dockerfile, is deprecated. To set author metadata for an image, use the +`org.opencontainers.image.authors` [OCI label](https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys). + +## Examples + +❌ Bad: don't use the `MAINTAINER` instruction + +```dockerfile +MAINTAINER moby@example.com +``` + +✅ Good: specify the author using the `org.opencontainers.image.authors` label + +```dockerfile +LABEL org.opencontainers.image.authors="moby@example.com" +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md new file mode 100644 index 0000000000..0e276d5b7b --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/multiple-instructions-disallowed.md @@ -0,0 +1,50 @@ +--- +title: MultipleInstructionsDisallowed +description: Multiple instructions of the same type should not be used in the same stage +aliases: + - /go/dockerfile/rule/multiple-instructions-disallowed/ +--- + +## Output + +```text +Multiple CMD instructions should not be used in the same stage because only the last one will be used +``` + +## Description + +If you have multiple `CMD`, `HEALTHCHECK`, or `ENTRYPOINT` instructions in your +Dockerfile, only the last occurrence is used. An image can only ever have one +`CMD`, `HEALTHCHECK`, and `ENTRYPOINT`. + +## Examples + +❌ Bad: Duplicate instructions. + +```dockerfile +FROM alpine +CMD echo "Hello, Norway!" +CMD echo "Hello, Sweden!" +# Only "Hello, Sweden!" will be printed +``` + +✅ Good: only one `CMD` instruction. + +```dockerfile +FROM alpine +CMD echo "Hello, Norway!"; echo "Hello, Sweden!" +``` + +You can have both a regular, top-level `CMD` +and a separate `CMD` for a `HEALTHCHECK` instruction. + +✅ Good: only one top-level `CMD` instruction. + +```dockerfile +FROM python:alpine +RUN apk add curl +HEALTHCHECK --interval=1s --timeout=3s \ + CMD curl -f http://localhost:8080 || exit 1 +CMD python -m http.server 8080 +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuations.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuations.md new file mode 100644 index 0000000000..78283cd47e --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/no-empty-continuations.md @@ -0,0 +1,54 @@ +--- +title: NoEmptyContinuations +description: Empty continuation lines will become errors in a future release +aliases: + - /go/dockerfile/rule/no-empty-continuations/ +--- + +## Output + +```text +Empty continuation line found in: RUN apk add gnupg curl +``` + +## Description + +Support for empty continuation (`/`) lines have been deprecated and will +generate errors in future versions of the Dockerfile syntax. + +Empty continuation lines are empty lines following a newline escape: + +```dockerfile +FROM alpine +RUN apk add \ + + gnupg \ + + curl +``` + +Support for such empty lines is deprecated, and a future BuildKit release will +remove support for this syntax entirely, causing builds to break. To avoid +future errors, remove the empty lines, or add comments, since lines with +comments aren't considered empty. + +## Examples + +❌ Bad: empty continuation line between `EXPOSE` and 80. + +```dockerfile +FROM alpine +EXPOSE \ + +80 +``` + +✅ Good: comments do not count as empty lines. + +```dockerfile +FROM alpine +EXPOSE \ +# Port +80 +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md new file mode 100644 index 0000000000..bde3509be8 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/reserved-stage-name.md @@ -0,0 +1,36 @@ +--- +title: ReservedStageName +description: Reserved words should not be used as stage names +aliases: + - /go/dockerfile/rule/reserved-stage-name/ +--- + +## Output + +```text +'scratch' is reserved and should not be used as a stage name +``` + +## Description + +Reserved words should not be used as names for stages in multi-stage builds. +The reserved words are: + +- `context` +- `scratch` + +## Examples + +❌ Bad: `scratch` and `context` are reserved names. + +```dockerfile +FROM alpine AS scratch +FROM alpine AS context +``` + +✅ Good: the stage name `builder` is not reserved. + +```dockerfile +FROM alpine AS builder +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md new file mode 100644 index 0000000000..6aa8214472 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/stage-name-casing.md @@ -0,0 +1,32 @@ +--- +title: StageNameCasing +description: Stage names should be lowercase +aliases: + - /go/dockerfile/rule/stage-name-casing/ +--- + +## Output + +```text +Stage name 'BuilderBase' should be lowercase +``` + +## Description + +To help distinguish Dockerfile instruction keywords from identifiers, this rule +forces names of stages in a multi-stage Dockerfile to be all lowercase. + +## Examples + +❌ Bad: mixing uppercase and lowercase characters in the stage name. + +```dockerfile +FROM alpine AS BuilderBase +``` + +✅ Good: stage name is all in lowercase. + +```dockerfile +FROM alpine AS builder-base +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md new file mode 100644 index 0000000000..c07b60115b --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-arg-in-from.md @@ -0,0 +1,54 @@ +--- +title: UndefinedArgInFrom +description: FROM command must use declared ARGs +aliases: + - /go/dockerfile/rule/undefined-arg-in-from/ +--- + +## Output + +```text +FROM argument 'VARIANT' is not declared +``` + +## Description + +This rule warns for cases where you're consuming an undefined build argument in +`FROM` instructions. + +Interpolating build arguments in `FROM` instructions can be a good way to add +flexibility to your build, and lets you pass arguments that overriding the base +image of a stage. For example, you might use a build argument to specify the +image tag: + +```dockerfile +ARG ALPINE_VERSION=3.20 + +FROM alpine:${ALPINE_VERSION} +``` + +This makes it possible to run the build with a different `alpine` version by +specifying a build argument: + +```console +$ docker buildx build --build-arg ALPINE_VERSION=edge . +``` + +This check also tries to detect and warn when a `FROM` instruction reference +miss-spelled built-in build arguments, like `BUILDPLATFORM`. + +## Examples + +❌ Bad: the `VARIANT` build argument is undefined. + +```dockerfile +FROM node:22${VARIANT} AS jsbuilder +``` + +✅ Good: the `VARIANT` build argument is defined. + +```dockerfile +ARG VARIANT="-alpine3.20" +FROM node:22${VARIANT} AS jsbuilder +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md new file mode 100644 index 0000000000..037e16bd23 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/undefined-var.md @@ -0,0 +1,55 @@ +--- +title: UndefinedVar +description: Variables should be defined before their use +aliases: + - /go/dockerfile/rule/undefined-var/ +--- + +## Output + +```text +Usage of undefined variable '$foo' +``` + +## Description + +Before you reference an environment variable or a build argument in a `RUN` +instruction, you should ensure that the variable is declared in the Dockerfile, +using the `ARG` or `ENV` instructions. + +Attempting to access an environment variable without explicitly declaring it +doesn't necessarily result in a build error, but it may yield an unexpected +result or an error later on in the build process. + +This check also attempts to detect if you're accessing a variable with a typo. +For example, given the following Dockerfile: + +```dockerfile +FROM alpine +ENV PATH=$PAHT:/app/bin +``` + +The check detects that `$PAHT` is undefined, and that it's probably a +misspelling of `PATH`. + +```text +Usage of undefined variable '$PAHT' (did you mean $PATH?) +``` + +## Examples + +❌ Bad: `$foo` is an undefined build argument. + +```dockerfile +FROM alpine AS base +COPY $foo . +``` + +✅ Good: declaring `foo` as a build argument before attempting to access it. + +```dockerfile +FROM alpine AS base +ARG foo +COPY $foo . +``` + diff --git a/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md new file mode 100644 index 0000000000..2e165323e4 --- /dev/null +++ b/_vendor/github.com/moby/buildkit/frontend/dockerfile/docs/rules/workdir-relative-path.md @@ -0,0 +1,48 @@ +--- +title: WorkdirRelativePath +description: Relative workdir without an absolute workdir declared within the build can have unexpected results if the base image changes +aliases: + - /go/dockerfile/rule/workdir-relative-path/ +--- + +## Output + +```text +Relative workdir 'app/src' can have unexpected results if the base image changes +``` + +## Description + +When specifying `WORKDIR` in a build stage, you can use an absolute path, like +`/build`, or a relative path, like `./build`. Using a relative path means that +the working directory is relative to whatever the previous working directory +was. So if your base image uses `/usr/local/foo` as a working directory, and +you specify a relative directory like `WORKDIR build`, the effective working +directory becomes `/usr/local/foo/build`. + +The `WorkdirRelativePath` build rule warns you if you use a `WORKDIR` with a +relative path without first specifying an absolute path in the same Dockerfile. +The rationale for this rule is that using a relative working directory for base +image built externally is prone to breaking, since working directory may change +upstream without warning, resulting in a completely different directory +hierarchy for your build. + +## Examples + +❌ Bad: this assumes that `WORKDIR` in the base image is `/` +(if that changes upstream, the `web` stage is broken). + +```dockerfile +FROM nginx AS web +WORKDIR usr/share/nginx/html +COPY public . +``` + +✅ Good: a leading slash ensures that `WORKDIR` always ends up at the desired path. + +```dockerfile +FROM nginx AS web +WORKDIR /usr/share/nginx/html +COPY public . +``` + diff --git a/_vendor/modules.txt b/_vendor/modules.txt index 54c2ad7cb0..c519137cdc 100644 --- a/_vendor/modules.txt +++ b/_vendor/modules.txt @@ -1,6 +1,6 @@ # github.com/moby/moby v26.1.2+incompatible -# github.com/moby/buildkit v0.13.1 +# github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc # github.com/docker/buildx v0.14.1 -# github.com/docker/cli v26.1.3+incompatible +# github.com/docker/cli v26.1.4+incompatible # github.com/docker/compose/v2 v2.27.0 # github.com/docker/scout-cli v1.9.3 diff --git a/go.mod b/go.mod index 34b3126ae7..2f31bd012b 100644 --- a/go.mod +++ b/go.mod @@ -6,10 +6,10 @@ toolchain go1.21.1 require ( github.com/docker/buildx v0.14.1 // indirect - github.com/docker/cli v26.1.3+incompatible // indirect + github.com/docker/cli v26.1.4+incompatible // indirect github.com/docker/compose/v2 v2.27.0 // indirect github.com/docker/scout-cli v1.9.3 // indirect - github.com/moby/buildkit v0.13.1 // indirect + github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc // indirect github.com/moby/moby v26.1.2+incompatible // indirect ) @@ -18,6 +18,6 @@ replace ( github.com/docker/cli => github.com/docker/cli v26.1.3-0.20240513184838-60f2d38d5341+incompatible github.com/docker/compose/v2 => github.com/docker/compose/v2 v2.27.0 github.com/docker/scout-cli => github.com/docker/scout-cli v1.9.3 - github.com/moby/buildkit => github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0 + github.com/moby/buildkit => github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc github.com/moby/moby => github.com/moby/moby v26.1.2+incompatible ) diff --git a/go.sum b/go.sum index 883dd0bd7e..2a3928e37c 100644 --- a/go.sum +++ b/go.sum @@ -242,6 +242,10 @@ github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0 h1:wTJCJDC1wo github.com/moby/buildkit v0.13.0-rc3.0.20240424175633-5fce077ed0e0/go.mod h1:wH5RTVyFjMQ67euC1e3UUSw7yQe7JkAHmf8OZkQY7Y4= github.com/moby/buildkit v0.13.0 h1:reVR1Y+rbNIUQ9jf0Q1YZVH5a/nhOixZsl+HJ9qQEGI= github.com/moby/buildkit v0.13.0/go.mod h1:aNmNQKLBFYAOFuzQjR3VA27/FijlvtBD1pjNwTSN37k= +github.com/moby/buildkit v0.14.0-rc2 h1:qvl0hOKeyAWReOkksNtstQjPNaAD4jN3Dvq4r7slqYM= +github.com/moby/buildkit v0.14.0-rc2/go.mod h1:/ZJNHNVso1nf063XlDhEkNEcRNW19utVpUKixCUo9Ks= +github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc h1:D/QzYP+52V4IzxMvcWe8ppgg0XptfI4/JCd7ry79gqY= +github.com/moby/buildkit v0.14.0-rc2.0.20240610193248-7da4d591c4dc/go.mod h1:1XssG7cAqv5Bz1xcGMxJL123iCv5TYN4Z/qf647gfuk= github.com/moby/locker v1.0.1/go.mod h1:S7SDdo5zpBK84bzzVlKr2V0hz+7x9hWbYC/kq7oQppc= github.com/moby/moby v24.0.2+incompatible h1:yH+5dRHH1x3XRKzl1THA2aGTy6CHYnkt5N924ADMax8= github.com/moby/moby v24.0.2+incompatible/go.mod h1:fDXVQ6+S340veQPv35CzDahGBmHsiclFwfEygB/TWMc=