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 has been 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?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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, orko
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?
The text was updated successfully, but these errors were encountered: