example: build-using-dockerfile

[AkihiroSuda]

This subcommand mimics docker build CLI flags so that Docker users can
more easily get started with BuildKit.

The command name was inspired by buildah bud.

Signed-off-by: Akihiro Suda suda.akihiro@lab.ntt.co.jp

[AkihiroSuda]

p.s. I know dockerfile is being removed from this repo (#163), but I think having this tool in this repo is ok for dev&demo purpose.

[tonistiigi]

Couldn't this be a wrapper outside the tree that we could promote from here. Not sure if we want to add helper commands that we know we will break in the future. Or maybe we could have a way to extend buildctl if you have binaries like buildctl-bud (similar to git).

[AkihiroSuda]

WDYT about having this command in the examples directory of this repo, so that people can try BuildKit without cloning multiple repos (which causes dependency hell)?

Or maybe we could have a way to extend buildctl if you have binaries like buildctl-bud (similar to git).

If buildctl is intended to be used as a dev tool (as in ctr and swarmctl), I wonder such extension is too much.
Is it rather planned to be used as a regular user command such as docker?

[tonistiigi]

@AkihiroSuda examples would be fine but I don't know why it would cause dependency hell if it is just a wrapper around buildctl.

If buildctl is intended to be used as a dev tool (as in ctr and swarmctl), I wonder such extension is too much.

Yes, I agree as it would be a stretch at the moment. We would need to have multiple use cases of such extensions to consider it.

[AkihiroSuda]

Updated PR, but plz feel free to close if this PR is not right.

I don't know why it would cause dependency hell if it is just a wrapper around buildctl.

Because the Go packages are not stabilized.

[tonistiigi]

Because the Go packages are not stabilized.

Ah, I thought this would just call buildctl directly. But using the client is fine as well (and has more tutorial value in examples folder this way).

[tonistiigi]

Can you update this to just produce the Docker tarball after #228 . So it works with build-using-dockerfile . | docker load.

Also, I'm not sure about the readme changes. Maybe we can do this in separate PR. I'm thinking moving the llb examples also under the "Examples" title under "LLB" subsection. This could be alternative under the "Building a Dockerfile". I think it is important to still show that buildctl build --frontend= is the main syntax and this is a nice shortcut if you want to do this repeatedly.

[AkihiroSuda]

updated

[tonistiigi]

Can you add a check to hack/test to confirm that this builds when we change anything(actually should do that for all the examples).

Not in this PR: Do you think we should change SolveOpt to take io.WriteCloser as output to avoid this tmpTar thing. The "output" isn't a real exporter-opt anyway as it is handled on the client side. buildctl could detect it and make it into a typed structure.

[tonistiigi]

@AkihiroSuda Actually, no need. go test ./... validates this already.

LGTM

[AkihiroSuda]

Do you think we should change SolveOpt to take io.WriteCloser as output to avoid this tmpTar thing.

👍

[tonistiigi]

Why is this a required value?

[AkihiroSuda]

It is just required for exportation.
We can remove it later.