vendor: bump buildkit 4f4e03067523b2fc5ca2f17514a5e75ad63e02fb

full diff: f7042823e3...4f4e030675

no changes to vendored files

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

vendor.conf

@@ -45,7 +45,7 @@ github.com/Microsoft/go-winio                       6c72808b55902eae4c5943626030
 github.com/Microsoft/hcsshim                        b3f49c06ffaeef24d09c6c08ec8ec8425a0303e2
 github.com/miekg/pkcs11                             cb39313ec884f2cd77f4762875fe96aecf68f8e3 # v1.0.2
 github.com/mitchellh/mapstructure                   f15292f7a699fcc1a38a80977f80a046874ba8ac
-github.com/moby/buildkit                            f7042823e340d38d1746aa675b83d1aca431cee3 # v0.6.1-71-gf7042823
+github.com/moby/buildkit                            4f4e03067523b2fc5ca2f17514a5e75ad63e02fb
 github.com/modern-go/concurrent                     bacd9c7ef1dd9b15be4a9909b8ac7a4e313eec94 # 1.0.3
 github.com/modern-go/reflect2                       4b7aa43c6742a2c18fdef89dd197aaae7dac7ccd # 1.0.1
 github.com/morikuni/aec                             39771216ff4c63d11f5e604076f9c45e8be1067b

vendor/github.com/moby/buildkit/README.md

@@ -1,6 +1,6 @@
 [![asciicinema example](https://asciinema.org/a/gPEIEo1NzmDTUu2bEPsUboqmU.png)](https://asciinema.org/a/gPEIEo1NzmDTUu2bEPsUboqmU)
 
-## BuildKit
+# BuildKit
 
 [![GoDoc](https://godoc.org/github.com/moby/buildkit?status.svg)](https://godoc.org/github.com/moby/buildkit/client/llb)
 [![Build Status](https://travis-ci.org/moby/buildkit.svg?branch=master)](https://travis-ci.org/moby/buildkit)
@@ -25,49 +25,107 @@ Read the proposal from https://github.com/moby/moby/issues/32925
 
 Introductory blog post https://blog.mobyproject.org/introducing-buildkit-17e056cc5317
 
+Join `#buildkit` channel on [Docker Community Slack](http://dockr.ly/slack)
+
 :information_source: If you are visiting this repo for the usage of experimental Dockerfile features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`, please refer to [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experimental.md).
 
-### Used by
+:information_source: [BuildKit has been integrated to `docker build` since Docker 18.06 .](https://docs.docker.com/develop/develop-images/build_enhancements/)
+You don't need to read this document unless you want to use the full-featured standalone version of BuildKit.
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+
+
+- [Used by](#used-by)
+- [Quick start](#quick-start)
+  - [Starting the `buildkitd` daemon:](#starting-the-buildkitd-daemon)
+  - [Exploring LLB](#exploring-llb)
+  - [Exploring Dockerfiles](#exploring-dockerfiles)
+    - [Building a Dockerfile with `buildctl`](#building-a-dockerfile-with-buildctl)
+    - [Building a Dockerfile using external frontend:](#building-a-dockerfile-using-external-frontend)
+    - [Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`](#building-a-dockerfile-with-experimental-features-like-run---mounttypebindcachetmpfssecretssh)
+  - [Output](#output)
+    - [Registry](#registry)
+    - [Local directory](#local-directory)
+    - [Docker tarball](#docker-tarball)
+    - [OCI tarball](#oci-tarball)
+    - [containerd image store](#containerd-image-store)
+- [Cache](#cache)
+  - [Garbage collection](#garbage-collection)
+  - [Export cache](#export-cache)
+    - [Inline (push image and cache together)](#inline-push-image-and-cache-together)
+    - [Registry (push image and cache separately)](#registry-push-image-and-cache-separately)
+    - [Local directory](#local-directory-1)
+    - [`--export-cache` options](#--export-cache-options)
+    - [`--import-cache` options](#--import-cache-options)
+  - [Consistent hashing](#consistent-hashing)
+- [Expose BuildKit as a TCP service](#expose-buildkit-as-a-tcp-service)
+  - [Load balancing](#load-balancing)
+- [Containerizing BuildKit](#containerizing-buildkit)
+  - [Kubernetes](#kubernetes)
+  - [Daemonless](#daemonless)
+- [Opentracing support](#opentracing-support)
+- [Running BuildKit without root privileges](#running-buildkit-without-root-privileges)
+- [Building multi-platform images](#building-multi-platform-images)
+- [Contributing](#contributing)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+## Used by
 
 BuildKit is used by the following projects:
 
--   [Moby & Docker](https://github.com/moby/moby/pull/37151)
+-   [Moby & Docker](https://github.com/moby/moby/pull/37151) (`DOCKER_BUILDKIT=1 docker build`)
 -   [img](https://github.com/genuinetools/img)
 -   [OpenFaaS Cloud](https://github.com/openfaas/openfaas-cloud)
 -   [container build interface](https://github.com/containerbuilding/cbi)
--   [Knative Build Templates](https://github.com/knative/build-templates)
+-   [Tekton Pipelines](https://github.com/tektoncd/catalog) (formerly [Knative Build Templates](https://github.com/knative/build-templates))
 -   [the Sanic build tool](https://github.com/distributed-containers-inc/sanic)
 -   [vab](https://github.com/stellarproject/vab)
 -   [Rio](https://github.com/rancher/rio)
+-   [PouchContainer](https://github.com/alibaba/pouch)
+-   [Docker buildx](https://github.com/docker/buildx)
 
-### Quick start
+## Quick start
 
-Dependencies:
+:information_source: For Kubernetes deployments, see [`examples/kubernetes`](./examples/kubernetes).
 
+BuildKit is composed of the `buildkitd` daemon and the `buildctl` client.
+While the `buildctl` client is available for Linux, macOS, and Windows, the `buildkitd` daemon is only available for Linux currently.
+
+The `buildkitd` daemon requires the following components to be installed:
 -   [runc](https://github.com/opencontainers/runc)
 -   [containerd](https://github.com/containerd/containerd) (if you want to use containerd worker)
 
-The following command installs `buildkitd` and `buildctl` to `/usr/local/bin`:
+The latest binaries of BuildKit are available [here](https://github.com/moby/buildkit/releases) for Linux, macOS, and Windows.
 
-```bash
+[Homebrew package](https://formulae.brew.sh/formula/buildkit) (unofficial) is available for macOS.
-$ make && sudo make install
+```console
+$ brew install buildkit
 ```
 
-You can also use `make binaries-all` to prepare `buildkitd.containerd_only` and `buildkitd.oci_only`.
+To build BuildKit from source, see [`.github/CONTRIBUTING.md`](./.github/CONTRIBUTING.md).
 
-#### Starting the buildkitd daemon:
+### Starting the `buildkitd` daemon:
+
+You need to run `buildkitd` as the root user on the host.
 
 ```bash
-buildkitd --debug --root /var/lib/buildkit
+$ sudo buildkitd
 ```
 
+To run `buildkitd` as a non-root user, see [`docs/rootless.md`](docs/rootless.md).
+
 The buildkitd daemon supports two worker backends: OCI (runc) and containerd.
 
 By default, the OCI (runc) worker is used. You can set `--oci-worker=false --containerd-worker=true` to use the containerd worker.
 
 We are open to adding more backends.
 
-#### Exploring LLB
+The buildkitd daemon listens gRPC API on `/run/buildkit/buildkitd.sock` by default, but you can also use TCP sockets.
+See [Expose BuildKit as a TCP service](#expose-buildkit-as-a-tcp-service).
+
+### Exploring LLB
 
 BuildKit builds are based on a binary intermediate format called LLB that is used for defining the dependency graph for processes running part of your build. tl;dr: LLB is to Dockerfile what LLVM IR is to C.
 
@@ -76,49 +134,23 @@ BuildKit builds are based on a binary intermediate format called LLB that is use
 -   Efficiently cacheable
 -   Vendor-neutral (i.e. non-Dockerfile languages can be easily implemented)
 
-See [`solver/pb/ops.proto`](./solver/pb/ops.proto) for the format definition.
+See [`solver/pb/ops.proto`](./solver/pb/ops.proto) for the format definition, and see [`./examples/README.md`](./examples/README.md) for example LLB applications.
 
-Currently, following high-level languages has been implemented for LLB:
+Currently, the following high-level languages has been implemented for LLB:
 
 -   Dockerfile (See [Exploring Dockerfiles](#exploring-dockerfiles))
 -   [Buildpacks](https://github.com/tonistiigi/buildkit-pack)
+-   [Mockerfile](https://matt-rickard.com/building-a-new-dockerfile-frontend/)
+-   [Gockerfile](https://github.com/po3rin/gockerfile)
 -   (open a PR to add your own language)
 
-For understanding the basics of LLB, `examples/buildkit*` directory contains scripts that define how to build different configurations of BuildKit itself and its dependencies using the `client` package. Running one of these scripts generates a protobuf definition of a build graph. Note that the script itself does not execute any steps of the build.
+### Exploring Dockerfiles
 
-You can use `buildctl debug dump-llb` to see what data is in this definition. Add `--dot` to generate dot layout.
+Frontends are components that run inside BuildKit and convert any build definition to LLB. There is a special frontend called gateway (`gateway.v0`) that allows using any image as a frontend.
 
-```bash
+During development, Dockerfile frontend (`dockerfile.v0`) is also part of the BuildKit repo. In the future, this will be moved out, and Dockerfiles can be built using an external image.
-go run examples/buildkit0/buildkit.go \
-    | buildctl debug dump-llb \
-    | jq .
-```
 
-To start building use `buildctl build` command. The example script accepts `--with-containerd` flag to choose if containerd binaries and support should be included in the end result as well.
+#### Building a Dockerfile with `buildctl`
-
-```bash
-go run examples/buildkit0/buildkit.go \
-    | buildctl build
-```
-
-`buildctl build` will show interactive progress bar by default while the build job is running. If the path to the trace file is specified, the trace file generated will contain all information about the timing of the individual steps and logs.
-
-Different versions of the example scripts show different ways of describing the build definition for this project to show the capabilities of the library. New versions have been added when new features have become available.
-
--   `./examples/buildkit0` - uses only exec operations, defines a full stage per component.
--   `./examples/buildkit1` - cloning git repositories has been separated for extra concurrency.
--   `./examples/buildkit2` - uses git sources directly instead of running `git clone`, allowing better performance and much safer caching.
--   `./examples/buildkit3` - allows using local source files for separate components eg. `./buildkit3 --runc=local | buildctl build --local runc-src=some/local/path`
--   `./examples/dockerfile2llb` - can be used to convert a Dockerfile to LLB for debugging purposes
--   `./examples/gobuild` - shows how to use nested invocation to generate LLB for Go package internal dependencies
-
-#### Exploring Dockerfiles
-
-Frontends are components that run inside BuildKit and convert any build definition to LLB. There is a special frontend called gateway (gateway.v0) that allows using any image as a frontend.
-
-During development, Dockerfile frontend (dockerfile.v0) is also part of the BuildKit repo. In the future, this will be moved out, and Dockerfiles can be built using an external image.
-
-##### Building a Dockerfile with `buildctl`
 
 ```bash
 buildctl build \
@@ -136,22 +168,7 @@ buildctl build \
 
 `--local` exposes local source files from client to the builder. `context` and `dockerfile` are the names Dockerfile frontend looks for build context and Dockerfile location.
 
-##### build-using-dockerfile utility
+#### Building a Dockerfile using external frontend:
-
-For people familiar with `docker build` command, there is an example wrapper utility in `./examples/build-using-dockerfile` that allows building Dockerfiles with BuildKit using a syntax similar to `docker build`.
-
-```bash
-go build ./examples/build-using-dockerfile \
-    && sudo install build-using-dockerfile /usr/local/bin
-
-build-using-dockerfile -t myimage .
-build-using-dockerfile -t mybuildkit -f ./hack/dockerfiles/test.Dockerfile .
-
-# build-using-dockerfile will automatically load the resulting image to Docker
-docker inspect myimage
-```
-
-##### Building a Dockerfile using [external frontend](https://hub.docker.com/r/docker/dockerfile/tags/):
 
 External versions of the Dockerfile frontend are pushed to https://hub.docker.com/r/docker/dockerfile-upstream and https://hub.docker.com/r/docker/dockerfile and can be used with the gateway frontend. The source for the external frontend is currently located in `./frontend/dockerfile/cmd/dockerfile-frontend` but will move out of this repository in the future ([#163](https://github.com/moby/buildkit/issues/163)). For automatic build from master branch of this repository `docker/dockerfile-upsteam:master` or `docker/dockerfile-upstream:master-experimental` image can be used.
 
@@ -168,7 +185,7 @@ buildctl build \
     --opt build-arg:APT_MIRROR=cdn-fastly.deb.debian.org
 ```
 
-##### Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`
+#### Building a Dockerfile with experimental features like `RUN --mount=type=(bind|cache|tmpfs|secret|ssh)`
 
 See [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experimental.md).
 
@@ -176,24 +193,26 @@ See [`frontend/dockerfile/docs/experimental.md`](frontend/dockerfile/docs/experi
 
 By default, the build result and intermediate cache will only remain internally in BuildKit. An output needs to be specified to retrieve the result.
 
-##### Exporting resulting image to containerd
+#### Registry
-
-The containerd worker needs to be used
-
-```bash
-buildctl build ... --output type=image,name=docker.io/username/image
-ctr --namespace=buildkit images ls
-```
-
-##### Push resulting image to registry
 
 ```bash
 buildctl build ... --output type=image,name=docker.io/username/image,push=true
 ```
 
-If credentials are required, `buildctl` will attempt to read Docker configuration file.
+To export and import the cache along with the image, you need to specify `--export-cache type=inline` and `--import-cache type=registry,ref=...`.
+See [Export cache](#export-cache).
 
-##### Exporting build result back to client
+```bash
+buildctl build ...\
+  --output type=image,name=docker.io/username/image,push=true \
+  --export-cache type=inline \
+  --import-cache type=registry,ref=docker.io/username/image
+```
+
+If credentials are required, `buildctl` will attempt to read Docker configuration file `$DOCKER_CONFIG/config.json`.
+`$DOCKER_CONFIG` defaults to `~/.docker`.
+
+#### Local directory
 
 The local client will copy the files directly to the client. This is useful if BuildKit is being used for building something else than container images.
 
@@ -222,70 +241,150 @@ buildctl build ... --output type=tar,dest=out.tar
 buildctl build ... --output type=tar > out.tar
 ```
 
-##### Exporting built image to Docker
+#### Docker tarball
 
 ```bash
 # exported tarball is also compatible with OCI spec
 buildctl build ... --output type=docker,name=myimage | docker load
 ```
 
-##### Exporting [OCI Image Format](https://github.com/opencontainers/image-spec) tarball to client
+#### OCI tarball
 
 ```bash
 buildctl build ... --output type=oci,dest=path/to/output.tar
 buildctl build ... --output type=oci > output.tar
 ```
+#### containerd image store
 
-### Exporting/Importing build cache (not image itself)
+The containerd worker needs to be used
-
-#### To/From registry
 
 ```bash
-buildctl build ... --export-cache type=registry,ref=localhost:5000/myrepo:buildcache
+buildctl build ... --output type=image,name=docker.io/username/image
-buildctl build ... --import-cache type=registry,ref=localhost:5000/myrepo:buildcache
+ctr --namespace=buildkit images ls
 ```
 
-#### To/From local filesystem
+To change the containerd namespace, you need to change `worker.containerd.namespace` in [`/etc/buildkit/buildkitd.toml`](./docs/buildkitd.toml.md).
 
-```bash
-buildctl build ... --export-cache type=local,dest=path/to/output-dir
-buildctl build ... --import-cache type=local,src=path/to/input-dir
-```
 
-The directory layout conforms to OCI Image Spec v1.0.
+## Cache
 
-#### `--export-cache` options
+To show local build cache (`/var/lib/buildkit`):
-
--   `mode=min` (default): only export layers for the resulting image
--   `mode=max`: export all the layers of all intermediate steps
--   `ref=docker.io/user/image:tag`: reference for `registry` cache exporter
--   `dest=path/to/output-dir`: directory for `local` cache exporter
-
-#### `--import-cache` options
-
--   `ref=docker.io/user/image:tag`: reference for `registry` cache importer
--   `src=path/to/input-dir`: directory for `local` cache importer
--   `digest=sha256:deadbeef`: digest of the manifest list to import for `local` cache importer. Defaults to the digest of "latest" tag in `index.json`
-
-### Other
-
-#### View build cache
 
 ```bash
 buildctl du -v
 ```
 
-#### Show enabled workers
+To prune local build cache:
-
 ```bash
-buildctl debug workers -v
+buildctl prune
 ```
 
-### Running containerized buildkit
+### Garbage collection
 
-BuildKit can also be used by running the `buildkitd` daemon inside a Docker container and accessing it remotely. The client tool `buildctl` is also available for Mac and Windows.
+See [`./docs/buildkitd.toml.md`](./docs/buildkitd.toml.md).
 
-We provide `buildkitd` container images as [`moby/buildkit`](https://hub.docker.com/r/moby/buildkit/tags/):
+### Export cache
+
+BuildKit supports the following cache exporters:
+* `inline`: embed the cache into the image, and push them to the registry together
+* `registry`: push the image and the cache separately
+* `local`: export to a local directory
+
+In most case you want to use the `inline` cache exporter.
+However, note that the `inline` cache exporter only supports `min` cache mode. 
+To enable `max` cache mode, push the image and the cache separately by using `registry` cache exporter.
+
+#### Inline (push image and cache together)
+
+```bash
+buildctl build ... \
+  --output type=image,name=docker.io/username/image,push=true \
+  --export-cache type=inline \
+  --import-cache type=registry,ref=docker.io/username/image
+```
+
+Note that the inline cache is not imported unless `--import-cache type=registry,ref=...` is provided.
+
+:information_source: Docker-integrated BuildKit (`DOCKER_BUILDKIT=1 docker build`) and `docker buildx`requires 
+`--build-arg BUILDKIT_INLINE_CACHE=1` to be specified to enable the `inline` cache exporter.
+However, the standalone `buildctl` does NOT require `--opt build-arg:BUILDKIT_INLINE_CACHE=1` and the build-arg is simply ignored.
+
+#### Registry (push image and cache separately)
+
+```bash
+buildctl build ... \
+  --output type=image,name=localhost:5000/myrepo:image,push=true \
+  --export-cache type=registry,ref=localhost:5000/myrepo:buildcache \
+  --import-cache type=registry,ref=localhost:5000/myrepo:buildcache \
+```
+
+#### Local directory
+
+```bash
+buildctl build ... --export-cache type=local,dest=path/to/output-dir
+buildctl build ... --import-cache type=local,src=path/to/input-dir,digest=sha256:deadbeef
+```
+
+The directory layout conforms to OCI Image Spec v1.0.
+
+Currently, you need to specify the `digest` of the manifest list to import for `local` cache importer. 
+This is planned to default to the digest of "latest" tag in `index.json` in future.
+
+#### `--export-cache` options
+-   `type`: `inline`, `registry`, or `local`
+-   `mode=min` (default): only export layers for the resulting image
+-   `mode=max`: export all the layers of all intermediate steps. Not supported for `inline` cache exporter.
+-   `ref=docker.io/user/image:tag`: reference for `registry` cache exporter
+-   `dest=path/to/output-dir`: directory for `local` cache exporter
+
+#### `--import-cache` options
+-   `type`: `registry` or `local`. Use `registry` to import `inline` cache.
+-   `ref=docker.io/user/image:tag`: reference for `registry` cache importer
+-   `src=path/to/input-dir`: directory for `local` cache importer
+-   `digest=sha256:deadbeef`: digest of the manifest list to import for `local` cache importer. 
+
+### Consistent hashing
+
+If you have multiple BuildKit daemon instances but you don't want to use registry for sharing cache across the cluster,
+consider client-side load balancing using consistent hashing.
+
+See [`./examples/kubernetes/consistenthash`](./examples/kubernetes/consistenthash).
+
+## Expose BuildKit as a TCP service
+
+The `buildkitd` daemon can listen the gRPC API on a TCP socket.
+
+It is highly recommended to create TLS certificates for both the daemon and the client (mTLS).
+Enabling TCP without mTLS is dangerous because the executor containers (aka Dockerfile `RUN` containers) can call BuildKit API as well.
+
+```bash
+buildkitd \
+  --addr tcp://0.0.0.0:1234 \
+  --tlscacert /path/to/ca.pem \
+  --tlscert /path/to/cert.pem \
+  --tlskey /path/to/key.pem
+```
+
+```bash
+buildctl \
+  --addr tcp://example.com:1234 \
+  --tlscacert /path/to/ca.pem \
+  --tlscert /path/to/clientcert.pem \
+  --tlskey /path/to/clientkey.pem \
+  build ...
+```
+
+### Load balancing
+
+`buildctl build` can be called against randomly load balanced the `buildkitd` daemon.
+
+See also [Consistent hashing](#consistenthashing) for client-side load balancing.
+
+## Containerizing BuildKit
+
+BuildKit can also be used by running the `buildkitd` daemon inside a Docker container and accessing it remotely.
+
+We provide the container images as [`moby/buildkit`](https://hub.docker.com/r/moby/buildkit/tags/):
 
 -   `moby/buildkit:latest`: built from the latest regular [release](https://github.com/moby/buildkit/releases)
 -   `moby/buildkit:rootless`: same as `latest` but runs as an unprivileged user, see [`docs/rootless.md`](docs/rootless.md)
@@ -295,11 +394,17 @@ We provide `buildkitd` container images as [`moby/buildkit`](https://hub.docker.
 To run daemon in a container:
 
 ```bash
-docker run -d --privileged -p 1234:1234 moby/buildkit:latest --addr tcp://0.0.0.0:1234
+docker run -d --name buildkitd --privileged moby/buildkit:latest
-export BUILDKIT_HOST=tcp://0.0.0.0:1234
+export BUILDKIT_HOST=docker-container://buildkitd
 buildctl build --help
 ```
 
+### Kubernetes
+
+For Kubernetes deployments, see [`examples/kubernetes`](./examples/kubernetes).
+
+### Daemonless
+
 To run client and an ephemeral daemon in a single container ("daemonless mode"):
 
 ```bash
@@ -335,21 +440,7 @@ docker run \
         --local dockerfile=/tmp/work
 ```
 
-The images can be also built locally using `./hack/dockerfiles/test.Dockerfile` (or `./hack/dockerfiles/test.buildkit.Dockerfile` if you already have BuildKit). Run `make images` to build the images as `moby/buildkit:local` and `moby/buildkit:local-rootless`.
+## Opentracing support
-
-#### Connection helpers
-
-If you are running `moby/buildkit:master` or `moby/buildkit:master-rootless` as a Docker/Kubernetes container, you can use special `BUILDKIT_HOST` URL for connecting to the BuildKit daemon in the container:
-
-```bash
-export BUILDKIT_HOST=docker-container://<container>
-```
-
-```bash
-export BUILDKIT_HOST=kube-pod://<pod>
-```
-
-### Opentracing support
 
 BuildKit supports opentracing for buildkitd gRPC API and buildctl commands. To capture the trace to [Jaeger](https://github.com/jaegertracing/jaeger), set `JAEGER_TRACE` environment variable to the collection address.
 
@@ -360,14 +451,15 @@ export JAEGER_TRACE=0.0.0.0:6831
 # any buildctl command should be traced to http://127.0.0.1:16686/
 ```
 
-### Supported runc version
+## Running BuildKit without root privileges
-
-During development, BuildKit is tested with the version of runc that is being used by the containerd repository. Please refer to [runc.md](https://github.com/containerd/containerd/blob/v1.2.1/RUNC.md) for more information.
-
-### Running BuildKit without root privileges
 
 Please refer to [`docs/rootless.md`](docs/rootless.md).
 
-### Contributing
+## Building multi-platform images
+
+See [`docker buildx` documentation](https://github.com/docker/buildx#building-multi-platform-images)
+
+## Contributing
 
 Want to contribute to BuildKit? Awesome! You can find information about contributing to this project in the [CONTRIBUTING.md](/.github/CONTRIBUTING.md)
+

vendor/github.com/moby/buildkit/go.mod

@@ -9,7 +9,7 @@ require (
 	github.com/codahale/hdrhistogram v0.0.0-20160425231609-f8ad88b59a58 // indirect
 	github.com/containerd/cgroups v0.0.0-20190717030353-c4b9ac5c7601 // indirect
 	github.com/containerd/console v0.0.0-20181022165439-0650fd9eeb50
-	github.com/containerd/containerd v1.3.0
+	github.com/containerd/containerd v1.4.0-0.20191014053712-acdcf13d5eaf
 	github.com/containerd/continuity v0.0.0-20190827140505-75bee3e2ccb6
 	github.com/containerd/fifo v0.0.0-20190816180239-bda0ff6ed73c // indirect
 	github.com/containerd/go-cni v0.0.0-20190813230227-49fbd9b210f3