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
{{ message }}
This repository was archived by the owner on Feb 23, 2024. It is now read-only.
There is a brief mention of non Dockerfile driven workflows with the buildType attribute, but there aren't any examples or narrative that explain how we expect this to work for non Dockerfile based things (i.e. Bazel, or cloud native build packs, or ko or other things that simply create a tgz of a layer and either append to an existing thing or build an entirely new manifest around it).
Is the initial scope for this going to be strictly limited to things in the realm of Buildkit / Dockerfile? Are there any important use cases within Azure services that would get missed by that assumption?
There is a brief mention of non Dockerfile driven workflows with the
buildTypeattribute, but there aren't any examples or narrative that explain how we expect this to work for non Dockerfile based things (i.e. Bazel, or cloud native build packs, orkoor other things that simply create a tgz of a layer and either append to an existing thing or build an entirely new manifest around it).Is the initial scope for this going to be strictly limited to things in the realm of Buildkit / Dockerfile? Are there any important use cases within Azure services that would get missed by that assumption?