Merge pull request #21896 from docker/published-update

publish updates from main

Author: dvdksn

content/guides/dotnet/containerize.md

@@ -60,7 +60,7 @@ Let's get started!
 
 ? What application platform does your project use? ASP.NET Core
 ? What's the name of your solution's main project? myWebApp
-? What version of .NET do you want to use? 6.0
+? What version of .NET do you want to use? 8.0
 ? What local port do you want to use to access your server? 8080
 ```
 

content/guides/dotnet/develop.md

@@ -307,19 +307,19 @@ The following is the updated Dockerfile.
 ```Dockerfile {hl_lines="10-13"}
 # syntax=docker/dockerfile:1
 
-FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build
+FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build
 ARG TARGETARCH
 COPY . /source
 WORKDIR /source/src
 RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
     dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
 
-FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS development
+FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS development
 COPY . /source
 WORKDIR /source/src
 CMD dotnet run --no-launch-profile
 
-FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine AS final
+FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS final
 WORKDIR /app
 COPY --from=build /app .
 ARG UID=10001
@@ -380,7 +380,7 @@ secrets:
     file: db/password.txt
 ```
 
-Your containerized application will now use the `mcr.microsoft.com/dotnet/sdk:6.0-alpine` image, which includes development tools like `dotnet test`. Continue to the next section to learn how you can run `dotnet test`.
+Your containerized application will now use the `mcr.microsoft.com/dotnet/sdk:8.0-alpine` image, which includes development tools like `dotnet test`. Continue to the next section to learn how you can run `dotnet test`.
 
 ## Summary
 

content/guides/dotnet/run-tests.md

@@ -36,7 +36,7 @@ You should see output that contains the following.
 Starting test execution, please wait...
 A total of 1 test files matched the specified pattern.
 
-Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net6.0/tests.dll (net6.0)
+Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net8.0/tests.dll (net8.0)
 ```
 
 To learn more about the command, see [docker compose run](/reference/cli/docker/compose/run/).
@@ -50,20 +50,20 @@ The following is the updated Dockerfile.
 ```dockerfile {hl_lines="9"}
 # syntax=docker/dockerfile:1
 
-FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS build
+FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS build
 ARG TARGETARCH
 COPY . /source
 WORKDIR /source/src
 RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages \
     dotnet publish -a ${TARGETARCH/amd64/x64} --use-current-runtime --self-contained false -o /app
 RUN dotnet test /source/tests
 
-FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS development
+FROM mcr.microsoft.com/dotnet/sdk:8.0-alpine AS development
 COPY . /source
 WORKDIR /source/src
 CMD dotnet run --no-launch-profile
 
-FROM mcr.microsoft.com/dotnet/aspnet:6.0-alpine AS final
+FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS final
 WORKDIR /app
 COPY --from=build /app .
 ARG UID=10001
@@ -92,16 +92,16 @@ You should see output containing the following.
 #11 1.564   Determining projects to restore...
 #11 3.421   Restored /source/src/myWebApp.csproj (in 1.02 sec).
 #11 19.42   Restored /source/tests/tests.csproj (in 17.05 sec).
-#11 27.91   myWebApp -> /source/src/bin/Debug/net6.0/myWebApp.dll
-#11 28.47   tests -> /source/tests/bin/Debug/net6.0/tests.dll
-#11 28.49 Test run for /source/tests/bin/Debug/net6.0/tests.dll (.NETCoreApp,Version=v6.0)
+#11 27.91   myWebApp -> /source/src/bin/Debug/net8.0/myWebApp.dll
+#11 28.47   tests -> /source/tests/bin/Debug/net8.0/tests.dll
+#11 28.49 Test run for /source/tests/bin/Debug/net8.0/tests.dll (.NETCoreApp,Version=v8.0)
 #11 28.67 Microsoft (R) Test Execution Command Line Tool Version 17.3.3 (x64)
 #11 28.67 Copyright (c) Microsoft Corporation.  All rights reserved.
 #11 28.68
 #11 28.97 Starting test execution, please wait...
 #11 29.03 A total of 1 test files matched the specified pattern.
 #11 32.07
-#11 32.08 Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net6.0/tests.dll (net6.0)
+#11 32.08 Passed!  - Failed:     0, Passed:     1, Skipped:     0, Total:     1, Duration: < 1 ms - /source/tests/bin/Debug/net8.0/tests.dll (net8.0)
 #11 DONE 32.2s
 ```
 

content/includes/hub-limits.md

@@ -4,5 +4,5 @@
 > [!NOTE]
 >
 > The Docker Hub plan limits will take effect on March 1, 2025. No charges on
-> Docker Hub image pulls or storage will be incurred between December 10, 2024,
+> Docker Hub pulls or storage will be incurred between December 10, 2024,
 > and February 28, 2025.

content/manuals/_index.md

@@ -51,7 +51,7 @@ params:
     description: Customize your Docker Desktop workflow.
     icon: extension
     link: /extensions/
-  - title: Testcontainers cloud
+  - title: Testcontainers Cloud
     description: Run integration tests, with real dependencies, in the cloud.
     icon: package_2
     link: https://testcontainers.com/cloud/docs/

content/manuals/billing/docker-hub-pricing.md

@@ -10,7 +10,7 @@ to help you understand your storage consumption and costs.
 
 > [!NOTE]
 >
-> Docker Hub plan limits will take effect on March 1, 2025. No charges on Docker Hub image pulls
+> Docker Hub plan limits will take effect on March 1, 2025. No charges on Docker Hub pulls
 or storage will be incurred from December 10, 2024 and February 28, 2025.
 
 ## How storage is measured

content/manuals/build/concepts/context.md

@@ -567,3 +567,193 @@ README-secret.md
 
 All of the README files are included. The middle line has no effect because
 `!README*.md` matches `README-secret.md` and comes last.
+
+## Named contexts
+
+In addition to the default build context (the positional argument to the
+`docker build` command), you can also pass additional named contexts to builds.
+
+Named contexts are specified using the `--build-context` flag, followed by a
+name-value pair. This lets you include files and directories from multiple
+sources during the build, while keeping them logically separated.
+
+```console
+$ docker build --build-context docs=./docs .
+```
+
+In this example:
+
+- The named `docs` context points to the `./docs` directory.
+- The default context (`.`) points to the current working directory.
+
+### Using named contexts in a Dockerfile
+
+Dockerfile instructions can reference named contexts as if they are stages in a
+multi-stage build.
+
+For example, the following Dockerfile:
+
+1. Uses a `COPY` instruction to copy files from the default context into the
+   current build stage.
+2. Bind mounts the files in a named context to process the files as part of the
+   build.
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM buildbase
+WORKDIR /app
+
+# Copy all files from the default context into /app/src in the build container
+COPY . /app/src
+RUN make bin
+
+# Mount the files from the named "docs" context to build the documentation
+RUN --mount=from=docs,target=/app/docs \
+    make manpages
+```
+
+### Use cases for named contexts
+
+Using named contexts allows for greater flexibility and efficiency when
+building Docker images. Here are some scenarios where using named contexts can
+be useful:
+
+#### Example: combine local and remote sources
+
+You can define separate named contexts for different types of sources. For
+example, consider a project where the application source code is local, but the
+deployment scripts are stored in a Git repository:
+
+```console
+$ docker build --build-context scripts=https://github.com/user/deployment-scripts.git .
+```
+
+In the Dockerfile, you can use these contexts independently:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM alpine:latest
+
+# Copy application code from the main context
+COPY . /opt/app
+
+# Run deployment scripts using the remote "scripts" context
+RUN --mount=from=scripts,target=/scripts /scripts/main.sh
+```
+
+#### Example: dynamic builds with custom dependencies
+
+In some scenarios, you might need to dynamically inject configuration files or
+dependencies into the build from external sources. Named contexts make this
+straightforward by allowing you to mount different configurations without
+modifying the default build context.
+
+```console
+$ docker build --build-context config=./configs/prod .
+```
+
+Example Dockerfile:
+
+```dockerfile
+# syntax=docker/dockerfile:1
+FROM nginx:alpine
+
+# Use the "config" context for environment-specific configurations
+COPY --from=config nginx.conf /etc/nginx/nginx.conf
+```
+
+#### Example: pin or override images
+
+You can refer to named contexts in a Dockerfile the same way you can refer to
+an image. That means you can change an image reference in your Dockerfile by
+overriding it with a named context. For example, given the following
+Dockerfile:
+
+```dockerfile
+FROM alpine:{{% param example_alpine_version %}}
+```
+
+If you want to force image reference to resolve to a different version, without
+changing the Dockerfile, you can pass a context with the same name to the
+build. For example:
+
+```console
+docker buildx build --build-context alpine:{{% param example_alpine_version %}}=docker-image://alpine:edge .
+```
+
+The `docker-image://` prefix marks the context as an image reference. The
+reference can be a local image or an image in your registry.
+
+### Named contexts with Bake
+
+[Bake](/manuals/build/bake/_index.md) is a tool built into `docker build` that
+lets you manage your build configuration with a configuration file. Bake fully
+supports named contexts.
+
+To define named contexts in a Bake file:
+
+```hcl {title=docker-bake.hcl}
+target "app" {
+  contexts = {
+    docs = "./docs"
+  }
+}
+```
+
+This is equivalent to the following CLI invocation:
+
+```console
+$ docker build --build-context docs=./docs .
+```
+
+#### Linking targets with named contexts
+
+In addition to making complex builds more manageable, Bake also provides
+additional features on top of what you can do with `docker build` on the CLI.
+You can use named contexts to create build pipelines, where one target depends
+on and builds on top of another. For example, consider a Docker build setup
+where you have two Dockerfiles:
+
+- `base.Dockerfile`: for building a base image
+- `app.Dockerfile`: for building an application image
+
+The `app.Dockerfile` uses the image produced by `base.Dockerfile` as it's base
+image:
+
+```dockerfile {title=app.Dockerfile}
+FROM mybaseimage
+```
+
+Normally, you would have to build the base image first, and then either load it
+to Docker Engine's local image store or push it to a registry. With Bake, you
+can reference other targets directly, creating a dependency between the `app`
+target and the `base` target.
+
+```hcl {title=docker-bake.hcl}
+target "base" {
+  dockerfile = "base.Dockerfile"
+}
+
+target "app" {
+  dockerfile = "app.Dockerfile"
+  contexts = {
+    # the target: prefix indicates that 'base' is a Bake target
+    mybaseimage = "target:base"
+  }
+}
+```
+
+With this configuration, references to `mybaseimage` in `app.Dockerfile` use
+the results from building the `base` target. Building the `app` target will
+also trigger a rebuild of `mybaseimage`, if necessary:
+
+```console
+$ docker buildx bake app
+```
+
+### Further reading
+
+For more information about working with named contexts, see:
+
+- [`--build-context` CLI reference](/reference/cli/docker/buildx/build.md#build-context)
+- [Using Bake with additional contexts](/manuals/build/bake/contexts.md)

content/manuals/build/exporters/image-registry.md

@@ -37,6 +37,7 @@ The following table describes the available parameters that you can pass to
 | `force-compression`    | `true`,`false`                         | `false` | Forcefully apply compression, see [compression][1]                                                                                                                                                                                  |
 | `rewrite-timestamp`    | `true`,`false`                         | `false` | Rewrite the file timestamps to the `SOURCE_DATE_EPOCH` value. See [build reproducibility][4] for how to specify the `SOURCE_DATE_EPOCH` value.                                                                                      |
 | `oci-mediatypes`       | `true`,`false`                         | `false` | Use OCI media types in exporter manifests, see [OCI Media types][2]                                                                                                                                                                 |
+| `oci-artifact`         | `true`,`false`                         | `false` | Attestations are formatted as OCI artifacts, see [OCI Media types][2]                                                                                                                                                               |
 | `unpack`               | `true`,`false`                         | `false` | Unpack image after creation (for use with containerd)                                                                                                                                                                               |
 | `store`                | `true`,`false`                         | `true`  | Store the result images to the worker's (for example, containerd) image store, and ensures that the image has all blobs in the content store. Ignored if the worker doesn't have image store (when using OCI workers, for example). |
 | `annotation.<key>`     | String                                 |         | Attach an annotation with the respective `key` and `value` to the built image,see [annotations][3]                                                                                                                                  |
@@ -45,6 +46,7 @@ The following table describes the available parameters that you can pass to
 [2]: _index.md#oci-media-types
 [3]: #annotations
 [4]: https://github.com/moby/buildkit/blob/master/docs/build-repro.md
+[5]: /manuals/build/metadata/attestations/_index.md#attestations-as-oci-artifacts
 
 ## Annotations