Skip to content

feat: support custom BuildKit frontends#83

Open
zachspar wants to merge 1 commit into
apple:mainfrom
zachspar:spar/arbitrary-build-frontend-support
Open

feat: support custom BuildKit frontends#83
zachspar wants to merge 1 commit into
apple:mainfrom
zachspar:spar/arbitrary-build-frontend-support

Conversation

@zachspar

@zachspar zachspar commented Jun 13, 2026

Copy link
Copy Markdown

Background

This PR implements my feature request in #82 to enable building images using custom BuildKit frontends (ie. # syntax=ghcr.io/builderhub/yamlfile:latest, BUILDKIT_SYNTAX, and explicit gateway.v0 metadata), while keeping the existing native dockerfile.v1 path for plain Dockerfiles.

Previously the shim always parsed the build file as a Dockerfile before the build started and always ran a hard-coded dockerfile.v1 frontend. That broke external frontends like Yamlfile with errors such as unknown instruction: apiVersion:.

New Approach

Native Dockerfiles keep existing shim-specific behavior. External frontends delegate to the declared frontend image via BuildKit’s gateway mechanism.

Eventually it would be nice if we wire frontend / frontend-opt metadata from container, but that is not a requirement to achieve the desired behavior.

flowchart TD
    Input[Build file bytes] --> Resolve[resolveFrontend]
    Resolve -->|native| Native[Skip external path]
    Native --> Parse[parseDockerfileMetadata + dockerfile.v1]
    Resolve -->|external| Skip[Skip Dockerfile parse]
    Skip --> Stage[stageBuildDefinition + fssync staging]
    Stage --> Gateway[forwardGateway to gateway.v0]
Loading

@zachspar zachspar force-pushed the spar/arbitrary-build-frontend-support branch from 51396f4 to 1a73baf Compare June 13, 2026 05:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant