Feature or enhancement request details
Background
BuildKit is frontend-agnostic and lets you point at any LLB-speaking frontend via the # syntax=... directive (or by configuring the frontend explicitly). A good example is the frontend I've built called Yamlfile.
Current Behavior
Right now the shim has Dockerfile-specific logic that gets in the way. This results in container build effectively being locked to Dockerfile even though the underlying BuildKit instance could run other frontends without issue.
If I try to build something with a custom frontend (Yamlfile for example), I receive the following error:
Error: unknown: "dockerfile parse error on line 2: unknown instruction: apiVersion:"
Extended Behavior
It would be useful if the shim stayed out of the way on the build-definition side and just did the protocol translation + file serving generically.
This would let people use any BuildKit frontend, like Yamlfile container build -f Yamlfile:
# syntax=ghcr.io/builderhub/yamlfile:latest
apiVersion: v1alpha1
targets:
hello:
from: alpine
steps:
- run:
command: echo "hello from Yamlfile" > /msg.txt
Code of Conduct
Feature or enhancement request details
Background
BuildKit is frontend-agnostic and lets you point at any LLB-speaking frontend via the
# syntax=...directive (or by configuring the frontend explicitly). A good example is the frontend I've built calledYamlfile.Current Behavior
Right now the shim has Dockerfile-specific logic that gets in the way. This results in
container buildeffectively being locked to Dockerfile even though the underlying BuildKit instance could run other frontends without issue.If I try to build something with a custom frontend (Yamlfile for example), I receive the following error:
Extended Behavior
It would be useful if the shim stayed out of the way on the build-definition side and just did the protocol translation + file serving generically.
This would let people use any BuildKit frontend, like Yamlfile
container build -f Yamlfile:Code of Conduct