You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently dont think there is an easy way to figure out what dockerfile syntax is going to be used if dockerfile does not define # syntax=... directive.
My understanding is that buildx pins a version of buildkit:
Sometimes it would be useful to know what capabilities are available in dockerfile syntax by being able to query/find out what version of dockerfile is used by default.
Perhaps docker buildx version can be extended to include that information or maybe adding docker buildx info command similar to docker info which will show more information about internal buildx sub-systems is going to be very useful.
The text was updated successfully, but these errors were encountered:
My understanding is that buildx pins a version of buildkit:
You can run docker buildx inspect to see the BuildKit version of the current builder instance (that can then be mapped to Dockerfile version). go.mod has the version buildx libraries used when it was compiled that could be different from the daemon version. For instances created with buildx create, they always use the latest stable buildkit version if one was not set with the flags.
Description
Currently dont think there is an easy way to figure out what dockerfile syntax is going to be used if dockerfile does not define
# syntax=...
directive.My understanding is that
buildx
pins a version ofbuildkit
:buildx/go.mod
Line 29 in afcb609
which in turn contains a
frontend
implementation in https://github.com/moby/buildkit/tree/28264b45d924d654616f1fba1467aa0a4cefaab5/frontendTo map that to dockerfile syntax as published in https://docs.docker.com/build/dockerfile/release-notes/ is non-trivial.
Sometimes it would be useful to know what capabilities are available in dockerfile syntax by being able to query/find out what version of dockerfile is used by default.
Perhaps
docker buildx version
can be extended to include that information or maybe addingdocker buildx info
command similar todocker info
which will show more information about internal buildx sub-systems is going to be very useful.The text was updated successfully, but these errors were encountered: