Merge pull request #21860 from docker/published-update

publish updates from main

content/manuals/admin/company/_index.md

@@ -42,6 +42,8 @@ aliases:
 - /docker-hub/creating-companies/
 ---
 
+{{< summary-bar feature_name="Company" >}}
+
 {{< include "admin-company-overview.md" >}}
 
 Learn how to administer a company in the following sections.

content/manuals/admin/company/new-company.md

@@ -6,6 +6,8 @@ aliases:
 - /docker-hub/new-company/
 ---
 
+{{< summary-bar feature_name="Company" >}}
+
 You can create a new company in the Docker Admin Console. Before you begin, you must:
 - Be the owner of the organization you want to add to your company
 - Have a Docker Business subscription

content/manuals/admin/company/organizations.md

@@ -4,6 +4,8 @@ keywords: company, multiple organizations, manage organizations
 title: Manage company organizations
 ---
 
+{{< summary-bar feature_name="Company" >}}
+
 You can manage the organizations in a company in the Docker Admin Console.
 
 {{< include "admin-early-access.md" >}}

content/manuals/admin/company/owners.md

@@ -6,6 +6,8 @@ aliases:
 - /docker-hub/company-owner/
 ---
 
+{{< summary-bar feature_name="Company" >}}
+
 A company can have multiple owners. Company owners have company-wide
 observability and can manage company-wide settings that apply to all associated
 organizations. In addition, company owners have the same access as organization

content/manuals/admin/company/users.md

@@ -4,6 +4,8 @@ keywords: company, company users, users, admin, Admin Console
 title: Manage company users
 ---
 
+{{< summary-bar feature_name="Company" >}}
+
 You can manage users at the company-level in the Docker Admin Console.
 
 {{% admin-users product="admin" layer="company" %}}

content/manuals/admin/deactivate-account.md

@@ -6,6 +6,8 @@ aliases:
 - /docker-hub/deactivate-account/
 ---
 
+{{< summary-bar feature_name="General admin" >}}
+
 You can deactivate an account at any time. This section describes the prerequisites and steps to deactivate an organization account. For information on deactivating a user account, see [Deactivate a user account](../accounts/deactivate-user-account.md).
 
 > [!WARNING]

content/manuals/admin/organization/activity-logs.md

@@ -7,6 +7,8 @@ aliases:
 - /docker-hub/audit-log/
 ---
 
+{{< summary-bar feature_name="Activity logs" >}}
+
 Activity logs display a chronological list of activities that occur at organization and repository levels. It provides a report to owners on all their member activities.
 
 With activity logs, owners can view and track:
@@ -18,10 +20,6 @@ For example, activity logs display activities such as the date when a repository
 
 Owners can also see the activity logs for their repository if the repository is part of the organization subscribed to a Docker Business or Team plan.
 
-> [!NOTE]
->
-> Activity logs requires a [Docker Team or Business subscription](/manuals/subscription/_index.md).
-
 ## Manage activity logs
 
 {{< tabs >}}

content/manuals/admin/organization/convert-account.md

@@ -7,6 +7,8 @@ aliases:
 - /docker-hub/convert-account/
 ---
 
+{{< summary-bar feature_name="Admin orgs" >}}
+
 You can convert an existing user account to an organization. This is useful if you need multiple users to access your account and the repositories that it’s connected to. Converting it to an organization gives you better control over permissions for these users through [teams](manage-a-team.md) and [roles](roles-and-permissions.md).
 
 When you convert a user account to an organization, the account is migrated to a Docker Team plan.

content/manuals/admin/organization/insights.md

@@ -4,9 +4,7 @@ keywords: organization, insights
 title: Insights
 ---
 
-> [!NOTE]
->
-> Insights requires a [Docker Business subscription](../../subscription/details.md#docker-business) and administrators must [enforce sign-in](/security/for-admins/enforce-sign-in/). This ensures users sign in with an account associated with their organization.
+{{< summary-bar feature_name="Insights" >}}
 
 Insights helps administrators visualize and understand how Docker is used within
 their organizations. With Insights, administrators can ensure their teams are
@@ -24,6 +22,12 @@ Key benefits include:
 - Optimized license use. Ensure that developers have access to advanced
   features provided by a Docker subscription.
 
+## Prerequisites
+
+- [Docker Business subscription](../../subscription/details.md#docker-business)
+- Administrators must [enforce sign-in](/security/for-admins/enforce-sign-in/) for users
+- Insights enabled by your Customer Success Manager
+
 ## View Insights for organization users
 
 {{< include "admin-early-access.md" >}}

content/manuals/admin/organization/manage-a-team.md

@@ -8,6 +8,8 @@ aliases:
 - /docker-hub/manage-a-team/
 ---
 
+{{< summary-bar feature_name="Admin orgs" >}}
+
 You can create teams for your organization in Docker Hub and the Docker Admin Console. You can [configure repository access for a team](#configure-repository-permissions-for-a-team) in Docker Hub.
 
 A team is a group of Docker users that belong to an organization. An organization can have multiple teams. An organization owner can then create new teams and add members to an existing team using their Docker ID or email address and by selecting a team the user should be part of. Members aren't required to be part of a team to be associated with an organization.

content/manuals/admin/organization/manage-products.md

@@ -5,6 +5,8 @@ description: Learn how to manage Docker products for your organization
 keywords: organization, tools, products
 ---
 
+{{< summary-bar feature_name="Admin orgs" >}}
+
 In this section, learn how to manage access and view usage of the Docker
 products for your organization. For more detailed information about each
 product, including how to set up and configure them, see the following manuals:

content/manuals/admin/organization/members.md

@@ -197,6 +197,8 @@ To update a member role:
 
 ## Export members CSV file
 
+{{< summary-bar feature_name="Admin orgs" >}}
+
 Owners can export a CSV file containing all members. The CSV file for a company contains the following fields:
 - Name: The user's name
 - Username: The user's Docker ID

content/manuals/admin/organization/onboard.md

@@ -11,6 +11,8 @@ aliases:
 - /docker-hub/onboard-business/
 ---
 
+{{< summary-bar feature_name="Admin orgs" >}}
+
 {{< include "admin-early-access.md" >}}
 
 Learn how to onboard your organization using Docker Hub or the Docker Admin Console.

content/manuals/admin/organization/orgs.md

@@ -8,6 +8,8 @@ aliases:
 - /docker-hub/orgs/
 ---
 
+{{< summary-bar feature_name="Admin orgs" >}}
+
 This section describes how to create an organization. Before you begin:
 
 - You need a [Docker ID](/accounts/create-account/)

content/manuals/build-cloud/_index.md

@@ -11,6 +11,8 @@ aliases:
   - /build/cloud/
 ---
 
+{{< summary-bar feature_name="Docker Build Cloud" >}}
+
 Docker Build Cloud is a service that lets you build your container images
 faster, both locally and in CI. Builds run on cloud infrastructure optimally
 dimensioned for your workloads, no configuration required. The service uses a

content/manuals/build/bake/_index.md

@@ -6,6 +6,8 @@ aliases:
   - /build/customize/bake/
 ---
 
+{{< summary-bar feature_name="Build bake" >}}
+
 Bake is a feature of Docker Buildx that lets you define your build configuration
 using a declarative file, as opposed to specifying a complex CLI expression. It
 also lets you run multiple builds concurrently with a single invocation.
@@ -14,7 +16,7 @@ A Bake file can be written in HCL, JSON, or YAML formats, where the YAML format
 is an extension of a Docker Compose file. Here's an example Bake file in HCL
 format:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 group "default" {
   targets = ["frontend", "backend"]
 }

content/manuals/build/bake/contexts.md

@@ -29,14 +29,13 @@ Supported context values are:
 
 ## Pinning alpine image
 
-```dockerfile
+```dockerfile {title=Dockerfile}
 # syntax=docker/dockerfile:1
 FROM alpine
 RUN echo "Hello world"
 ```
 
-```hcl
-# docker-bake.hcl
+```hcl {title=docker-bake.hcl}
 target "app" {
   contexts = {
     alpine = "docker-image://alpine:3.13"
@@ -46,16 +45,14 @@ target "app" {
 
 ## Using a secondary source directory
 
-```dockerfile
-# syntax=docker/dockerfile:1
-FROM scratch AS src
-
+```dockerfile {title=Dockerfile}
 FROM golang
 COPY --from=src . .
 ```
 
-```hcl
-# docker-bake.hcl
+```hcl {title=docker-bake.hcl}
+# Running `docker buildx bake app` will result in `src` not pointing
+# to some previous build stage but to the client filesystem, not part of the context.
 target "app" {
   contexts = {
     src = "../path/to/source"
@@ -68,14 +65,16 @@ target "app" {
 To use a result of one target as a build context of another, specify the target
 name with `target:` prefix.
 
-```dockerfile
+```dockerfile {title=baseapp.Dockerfile}
+FROM scratch
+```
+```dockerfile {title=Dockerfile}
 # syntax=docker/dockerfile:1
 FROM baseapp
 RUN echo "Hello world"
 ```
 
-```hcl
-# docker-bake.hcl
+```hcl {title=docker-bake.hcl}
 target "base" {
   dockerfile = "baseapp.Dockerfile"
 }
@@ -119,7 +118,7 @@ result in significant impact on build time, depending on your build
 configuration. For example, say you have a Bake file that defines the following
 group of targets:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 group "default" {
   targets = ["target1", "target2"]
 }
@@ -148,7 +147,7 @@ context that only loads the context files, and have each target that needs
 those files reference that named context. For example, the following Bake file
 defines a named target `ctx`, which is used by both `target1` and `target2`:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 group "default" {
   targets = ["target1", "target2"]
 }
@@ -177,7 +176,7 @@ The named context `ctx` represents a Dockerfile stage, which copies the files
 from its context (`.`). Other stages in the Dockerfile can now reference the
 `ctx` named context and, for example, mount its files with `--mount=from=ctx`.
 
-```dockerfile
+```dockerfile {title=Dockerfile}
 FROM scratch AS ctx
 COPY --link . .
 

content/manuals/build/bake/expressions.md

@@ -30,7 +30,7 @@ Printing the Bake file with the `--print` flag shows the evaluated value for
 the `answer` build argument.
 
 ```console
-$ docker buildx bake --print app
+$ docker buildx bake --print
 ```
 
 ```json
@@ -76,13 +76,8 @@ $ docker buildx bake --print
 
 ```json
 {
-  "group": {
-    "default": {
-      "targets": ["default"]
-    }
-  },
   "target": {
-    "webapp": {
+    "default": {
       "context": ".",
       "dockerfile": "Dockerfile",
       "tags": ["my-image:latest"]

content/manuals/build/bake/inheritance.md

@@ -10,7 +10,7 @@ Targets can inherit attributes from other targets, using the `inherits`
 attribute. For example, imagine that you have a target that builds a Docker
 image for a development environment:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "app-dev" {
   args = {
     GO_VERSION = "{{% param example_go_version %}}"
@@ -28,7 +28,7 @@ slightly different attributes for a production build. In this example, the
 `app-release` target inherits the `app-dev` target, but overrides the `tags`
 attribute and adds a new `platforms` attribute:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "app-release" {
   inherits = ["app-dev"]
   tags = ["docker.io/username/myapp:latest"]
@@ -43,7 +43,7 @@ shared attributes for all or many of the build targets in the project. For
 example, the following `_common` target defines a common set of build
 arguments:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "_common" {
   args = {
     GO_VERSION = "{{% param example_go_version %}}"
@@ -55,7 +55,7 @@ target "_common" {
 You can then inherit the `_common` target in other targets to apply the shared
 attributes:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "lint" {
   inherits = ["_common"]
   dockerfile = "./dockerfiles/lint.Dockerfile"
@@ -88,7 +88,7 @@ When a target inherits another target, it can override any of the inherited
 attributes. For example, the following target overrides the `args` attribute
 from the inherited target:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "app-dev" {
   inherits = ["_common"]
   args = {
@@ -110,7 +110,7 @@ The `inherits` attribute is a list, meaning you can reuse attributes from
 multiple other targets. In the following example, the app-release target reuses
 attributes from both the `app-dev` and `_common` targets.
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "_common" {
   args = {
     GO_VERSION = "{{% param example_go_version %}}"

content/manuals/build/bake/introduction.md

@@ -71,7 +71,7 @@ $ docker build \
 
 The Bake equivalent would be:
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "myapp" {
   context = "."
   dockerfile = "Dockerfile"

content/manuals/build/bake/matrices.md

@@ -19,7 +19,7 @@ should resolve, use the name attribute.
 The following example resolves the app target to `app-foo` and `app-bar`. It
 also uses the matrix value to define the [target build stage](/build/bake/reference/#targettarget).
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "app" {
   name = "app-${tgt}"
   matrix = {
@@ -73,7 +73,7 @@ The following example builds four targets:
 - `app-bar-1-0`
 - `app-bar-2-0`
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "app" {
   name = "app-${tgt}-${replace(version, ".", "-")}"
   matrix = {
@@ -98,7 +98,7 @@ The following example builds two targets:
 - `app-foo-1-0`
 - `app-bar-2-0`
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "app" {
   name = "app-${item.tgt}-${replace(item.version, ".", "-")}"
   matrix = {

content/manuals/build/bake/remote-definition.md

@@ -91,7 +91,7 @@ execution context as named contexts.
 The following example defines the `docs` context as `./src/docs/content`,
 relative to the current working directory where Bake is run as a named context.
 
-```hcl
+```hcl {title=docker-bake.hcl}
 target "default" {
   contexts = {
     docs = "cwd://src/docs/content"