[pull] master from moby:master

.github/CONTRIBUTING.md

@@ -18,7 +18,6 @@ We also like to send gifts—if you're into schwag, make sure to let
 us know. We currently do not offer a paid security bounty program, but are not
 ruling it out in the future.
 
-
 ## Reporting other issues
 
 A great way to contribute to the project is to send a detailed report when you
@@ -52,59 +51,146 @@ Dependencies:
 - [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`:
 
 ```bash
 make && sudo make install
 ```
 
-You can also use `make binaries-all` to prepare `buildkitd.containerd_only` and `buildkitd.oci_only`.
-
 To build containerized `moby/buildkit:local` and `moby/buildkit:local-rootless` images:
 ```bash
 make images
 ```
 
+### Run BuildKit
+
+You can launch the backend BuildKit daemon either in a container, or directly:
+
+```bash
+# run the daemon in a container
+$ docker run --rm -d --name buildkitd --privileged moby/buildkit:local
+$ export BUILDKIT_HOST=docker-container://buildkitd
+$ buildctl debug info
+BuildKit: github.com/moby/buildkit v0.11.0-rc3-623-g2ff0d2a2f.m 2ff0d2a2f53663aae917980fa27eada7950ff69c.m
+```
+
+```bash
+# run the daemon directly (only on linux)
+$ sudo buildkitd
+$ export BUILDKIT_HOST=unix:///run/buildkit/buildkitd.sock
+$ sudo buildctl debug info
+BuildKit: github.com/moby/buildkit v0.11.0-rc3-506-g539bab193.m 539bab193c28d3ce731e6013f471ba24848f5c41.m
+```
+
+You can also connect buildx to the BuildKit daemon using the [`remote` driver](https://docs.docker.com/build/drivers/remote/):
+
+```bash
+$ docker buildx create --driver=remote --name=dev $BUILDKIT_HOST
+$ docker buildx --builder=dev inspect
+Name:          dev
+Driver:        remote
+Last Activity: 2023-06-06 14:15:52 +0000 UTC
+
+Nodes:
+Name:      dev0
+Endpoint:  tcp://localhost:1234
+Status:    running
+Buildkit:  v0.11.0-rc3-506-g539bab193.m
+Platforms: linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386
+```
+
+### Run BuildKit using Buildx
+
+You can also have buildx run and manage the custom BuildKit daemon itself using
+the [`docker-container` driver](https://docs.docker.com/build/drivers/remote/).
+
+This is usually the easiest way to get started with a custom BuildKit daemon
+for development or debugging.
+
+```bash
+$ docker buildx rm dev || true # remove previous dev builder if exists
+$ docker buildx create --driver=docker-container --name=dev --driver-opt image=moby/buildkit:local --bootstrap
+[+] Building 0.3s (1/1) FINISHED                                                                                                                           
+ => [internal] booting buildkit
+ => => starting container buildx_buildkit_dev0
+dev
+$ docker buildx --builder=dev inspect
+Name:          dev
+Driver:        docker-container
+Last Activity: 2023-06-06 14:15:52 +0000 UTC
+
+Nodes:
+Name:           dev0
+Endpoint:       desktop-linux
+Driver Options: image="moby/buildkit:local"
+Status:         running
+Buildkit:       v0.11.0-rc3-623-g2ff0d2a2f.m
+Platforms:      linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
+```
+
 ### Run the unit- and integration-tests
 
 Running tests:
 
 ```bash
-make test
+./hack/test integration gateway dockerfile
 ```
 
-This runs all unit and integration tests in a containerized environment.
+This runs all unit and integration tests, gateway client and dockerfile tests in a containerized environment.
 Locally, every package can be tested separately with standard Go tools, but
 integration tests are skipped if local user doesn't have enough permissions or
-worker binaries are not installed.
+worker binaries are not installed. The dockerfile tests run by first building new Dockerfile frontend
+image and then loading it to the test environment. Builtin Dockerfile frontend can be tested with regular
+integration tests.
 
 ```bash
 # test a specific package only
-make test TESTPKGS=./client
+TESTPKGS=./client ./hack/test integration
 
 # run a specific test with all worker combinations
-make test TESTPKGS=./client TESTFLAGS="--run /TestCallDiskUsage -v"
+TESTPKGS=./client TESTFLAGS="--run /TestCallDiskUsage -v" ./hack/test integration
 
 # run all integration tests with a specific worker
 # supported workers: oci, oci-rootless, containerd, containerd-1.1
-make test TESTPKGS=./client TESTFLAGS="--run //worker=containerd -v"
+TESTPKGS=./client TESTFLAGS="--run //worker=containerd -v" ./hack/test integration
+
+# run a specific dockerfile test only on labs channel
+DOCKERFILE_RELEASES=labs TESTFLAGS="--run /TestRunGlobalNetwork/worker=oci$/ -v" ./hack/test dockerfile
+
+# enabling go data race detector
+CGO_ENABLED=1 GOBUILDFLAGS="-race" ./hack/test integration
 ```
 
-Updating vendored dependencies:
+Set `TEST_KEEP_CACHE=1` for the test framework to keep external dependant images in a docker volume
+if you are repeatedly calling `./hack/test` script. This helps to avoid rate limiting on the remote registry side.
+
+You can also set `MOUNT_BUILDKIT_DOCKER_CONFIG_PATH` to forward docker config that will be used to pull
+test images into the container. Don't use your personal docker config, create a new one with a dedicated
+token that only has public read-only access.
+
+If you are working behind a proxy, you can set some of or all
+`HTTP_PROXY=http://ip:port`, `HTTPS_PROXY=http://ip:port`, `NO_PROXY=http://ip:port` for the test framework
+to specify the proxy build args.
+
+### Run the helper commands
+
+To validate PRs before submitting them you should run:
 
 ```bash
-# update vendor.conf
-make vendor
+$ make validate-all
 ```
 
-Validating your updates before submission:
+To generate new vendored files with go modules run:
 
 ```bash
-make validate-all
+$ make vendor
 ```
 
+To generate new versions of automatically generated files run:
 
+```bash
+$ make generated-files
+```
 
 ### Pull requests are always welcome
 
@@ -144,7 +230,7 @@ otherwise cleanup our project.
     <td>
       <p>
         Register for the Docker Community Slack (dockercommunity.slack.com)
-        <a href="https://join.slack.com/t/dockercommunity/shared_invite/enQtNDY4MDc1Mzc0MzIwLTgxZDBlMmM4ZGEyNDc1N2FkMzlhODJkYmE1YTVkYjM1MDE3ZjAwZjBkOGFlOTJkZjRmZGYzNjYyY2M3ZTUxYzQ" target="_blank">Click here for an invite to docker community slack</a>.
+        <a href="https://dockr.ly/comm-slack" target="_blank">Click here for an invite to docker community slack</a>.
         You'll find us in <code>#buildkit</code> channel, and the <code>#moby-project</code> channel for general discussions.
       </p>
     </td>
@@ -320,13 +406,11 @@ down to one.
   from the Git history.
 - See the [Coding Style](#coding-style) for further guidelines.
 
-
 ### Merge approval
 
 Project maintainers use LGTM (Looks Good To Me) in comments on the code review to
 indicate acceptance, or use the Github review approval feature.
 
-
 ## Coding Style
 
 Unless explicitly stated, we follow all coding guidelines from the Go
@@ -343,29 +427,29 @@ mind when nudging others to comply.
 
 The rules:
 
-1. All code should be formatted with `gofmt -s`.
-2. All code should pass the default levels of
-   [`golint`](https://github.com/golang/lint).
-3. All code should follow the guidelines covered in [Effective
-   Go](http://golang.org/doc/effective_go.html) and [Go Code Review
-   Comments](https://github.com/golang/go/wiki/CodeReviewComments).
-4. Comment the code. Tell us the why, the history and the context.
-5. Document _all_ declarations and methods, even private ones. Declare
-   expectations, caveats and anything else that may be important. If a type
-   gets exported, having the comments already there will ensure it's ready.
-6. Variable name length should be proportional to its context and no longer.
-   `noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo`.
-   In practice, short methods will have short variable names and globals will
-   have longer names.
-7. No underscores in package names. If you need a compound name, step back,
-   and re-examine why you need a compound name. If you still think you need a
-   compound name, lose the underscore.
-8. No utils or helpers packages. If a function is not general enough to
-   warrant its own package, it has not been written generally enough to be a
-   part of a util package. Just leave it unexported and well-documented.
-9. All tests should run with `go test` and outside tooling should not be
-   required. No, we don't need another unit testing framework. Assertion
-   packages are acceptable if they provide _real_ incremental value.
+1.  All code should be formatted with `gofmt -s`.
+2.  All code should pass the default levels of
+    [`golint`](https://github.com/golang/lint).
+3.  All code should follow the guidelines covered in [Effective
+    Go](http://golang.org/doc/effective_go.html) and [Go Code Review
+    Comments](https://github.com/golang/go/wiki/CodeReviewComments).
+4.  Comment the code. Tell us the why, the history and the context.
+5.  Document _all_ declarations and methods, even private ones. Declare
+    expectations, caveats and anything else that may be important. If a type
+    gets exported, having the comments already there will ensure it's ready.
+6.  Variable name length should be proportional to its context and no longer.
+    `noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo`.
+    In practice, short methods will have short variable names and globals will
+    have longer names.
+7.  No underscores in package names. If you need a compound name, step back,
+    and re-examine why you need a compound name. If you still think you need a
+    compound name, lose the underscore.
+8.  No utils or helpers packages. If a function is not general enough to
+    warrant its own package, it has not been written generally enough to be a
+    part of a util package. Just leave it unexported and well-documented.
+9.  All tests should run with `go test` and outside tooling should not be
+    required. No, we don't need another unit testing framework. Assertion
+    packages are acceptable if they provide _real_ incremental value.
 10. Even though we call these "rules" above, they are actually just
     guidelines. Since you've read all the rules, you now know that.
 

.github/ISSUE_TEMPLATE/bug.yml

@@ -0,0 +1,76 @@
+name: Bug Report
+description: File a bug report.
+type: "bug"
+labels:
+  - status/triage
+body:
+  - type: markdown
+    attributes:
+      value: |
+        **Thank you for taking the time to report a bug!**
+        If this is a security issue please report it to the [Docker Security team](mailto:[email protected]), see [SECURITY.md](https://github.com/moby/buildkit/blob/master/.github/SECURITY.md) for more information.
+
+  - type: checkboxes
+    attributes:
+      label: Contributing guidelines and issue reporting guide
+      description: |
+        Please read the contributing guidelines and issue reporting guide before proceeding.
+      options:
+        - label: I've read the [contributing guidelines](https://github.com/moby/buildkit/blob/master/.github/CONTRIBUTING.md) and wholeheartedly agree. I've also read the [issue reporting guide](https://github.com/moby/buildkit/blob/master/.github/issue_reporting_guide.md).
+          required: true
+
+  - type: checkboxes
+    attributes:
+      label: Well-formed report checklist
+      description: |
+        Make sure that your request fulfills all of the following requirements.
+        If one requirement cannot be satisfied, explain in detail why.
+      options:
+        - label: I have found a bug that the documentation does not mention anything about my problem
+          required: true
+        - label: I have found a bug that there are no open or closed issues that are related to my problem
+          required: true
+        - label: I have provided version/information about my environment and done my best to provide a reproducer
+          required: true
+
+  - type: textarea
+    attributes:
+      label: Description of bug
+      description: |
+        Please provide a description of the bug, reproduction steps and version information.
+
+        <details>
+        <summary>How to collect version information</summary>
+
+        Using `buildctl` and `buildkitd` to get version information
+        ```bash
+        buildctl --version && buildkitd version
+        ```
+
+        Using `docker` to get BuildKit information
+        ```bash
+        docker buildx version && docker buildx inspect
+        ```
+
+        Add Docker Engine information (if available)
+        ```bash
+        docker version && docker info
+        ```
+
+        </details>
+      value: |
+        ## Bug description
+
+        A description of the bug, observed, and expected behaviour.
+
+        ## Reproduction
+
+        Steps to reproduce the problem. If you are using `docker build` or `docker buildx build` providing the command as well as any input files will help analysis.
+
+        ## Version information
+
+        ```bash
+        terminal_output
+        ```
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,12 @@
+# https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#configuring-the-template-chooser
+blank_issues_enabled: true
+contact_links:
+  - name: Questions and Discussions
+    url: https://github.com/moby/buildkit/discussions/new
+    about: Use Github Discussions to ask questions and/or open discussion topics.
+  - name: Documentation
+    url: https://github.com/moby/buildkit/tree/master/docs
+    about: Read the documentation.
+  - name: Join the Docker Community on Slack
+    url: http://dockr.ly/comm-slack
+    about: Join the Docker Community on Slack and head to the buildkit channel.

.github/ISSUE_TEMPLATE/feature.yml

@@ -0,0 +1,14 @@
+name: Feature or enhancement request
+description: Missing functionality? Come tell us about it!
+type: "enhancement"
+labels:
+  - status/triage
+
+body:
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: What is the feature you want to see?
+    validations:
+      required: true

.github/SECURITY.md

@@ -0,0 +1,15 @@
+# Reporting security issues
+
+The project maintainers take security seriously. If you discover a security
+issue, please bring it to their attention right away!
+
+**Please _DO NOT_ file a public issue**, instead send your report privately to
+[[email protected]](mailto:[email protected]).
+
+
+Explanation of BuildKit security boundary and what we consider a security issue can be found in [here](/PROJECT.md#security-boundary). If you are unsure if you have found a security issue, it is always better to check privately first.
+
+Security reports are greatly appreciated, and we will publicly thank you for it
+(if you want to). We also like to send gifts—if you're into schwag, make
+sure to let us know. We currently do not offer a paid security bounty program,
+but are not ruling it out in the future.

.github/dependabot.yml

@@ -0,0 +1,15 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    open-pull-requests-limit: 10
+    directory: "/"
+    schedule:
+      interval: "daily"
+    ignore:
+      # ignore this dependency
+      # it seems a bug with dependabot as pining to commit sha should not
+      # trigger a new version: https://github.com/docker/buildx/pull/2222#issuecomment-1919092153
+      - dependency-name: "docker/docs"
+    labels:
+      - "area/dependencies"
+      - "bot"