moby / moby/buildkit

[RFC] Warn on unknown flags instead of failing

Open
#799 2 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area/dockerfile area/ux kind/enhancement
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 --mount seems 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.