[RFC] Warn on unknown flags instead of failing
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 10.3k
- Forks
- 1.5k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 50
Description
I was trying to optimize a Dockerfile, making use of the experimental --mount=type=cache feature.
# syntax = docker/dockerfile:1-experimental
FROM alpine
RUN --mount=type=cache,target=/var/cache/apk \
apk add ca-certificates
However, this feature is only available in the experimental syntax, which means that the Dockerfile can no longer be built without buildkit enabled;
DOCKER_BUILDKIT=0 docker build .
Sending build context to Docker daemon 2.048kB
Error response from daemon: Dockerfile parse error line 3: Unknown flag: mount
It would be great to be able to write optimized Dockerfiles (taking advantage of new features), but ignore the new features when using the classic builder.
Looking at the --mount options specifically, ignoring these options (printing a warning) on the classic builder would cause;
| backward compatible? | type= |
when missing |
|---|---|---|
| ✅ ❓ | bind |
build will likely fail if the mounted files are missing. Result therefore is the same as before (build fails due to feature not supported) |
| ✅ | cache |
build succeeds, but cache is written to the image layer |
| ✅ | tmpfs |
build succeeds, but files are written to the image layer |
| ✅ | secret |
build fails due to missing secrets. Result therefore is the same as before (build fails due to feature not supported) |
| ✅ | ssh |
build fails due to missing access to SSH keys. Result therefore is the same as before (build fails due to feature not supported) |
I realize this is a tricky one;
- Implementing this may ease the transition to BuildKit; people can start using some of the new features in their Dockerfiles, without necessarily breaking builds for users that have not yet made the transition.
- Although
--mountseems to be ok; other new features may not be? - This could be configurable. Doing so allows a user to opt-out of this behavior (or opt-in), but won't really solve the use-case (writing a Dockerfile with "progressive enhancement")
Note that new commands / Dockerfile instructions would still result in a hard failure.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The payload names no source files or tests. Start by locating the classic-builder Dockerfile parser and its handling of RUN flags, then compare how unknown instructions remain errors. Done means the warning and ignore behavior is defined for unknown flags without changing hard failures for unknown instructions, with tests covering the listed compatibility cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, dockerfile
- Domain
- build-system, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100