-
+
-
+
Windows: SHA-256 5f6db3cf5a2084fc7c584c90792f38a0caac91c4eed4f8653dde7bb8148517f1
diff --git a/desktop/settings/mac.md b/desktop/settings/mac.md
index e1c1bab0b6..7f1ec35a9b 100644
--- a/desktop/settings/mac.md
+++ b/desktop/settings/mac.md
@@ -50,6 +50,27 @@ On the **General** tab, you can configure when to start Docker and specify other
- **Use Docker Compose V2**. Select to enable the `docker-compose` command to
use Docker Compose V2. For more information, see [Docker Compose V2](../../compose/compose-v2/index.md).
+## Advanced
+
+On the **Advanced** tab, you can reconfigure your initial installation settings:
+
+- **Choose how to configure the installation of Docker's CLI tools**.
+ - **System**: Docker CLI tools are installed in the system directory under `/usr/local/bin`
+ - **User**: Docker CLI tools are installed in the user directory under `$HOME/.docker/bin`. You must then add `$HOME/.docker/bin` to your PATH. To add `$HOME/.docker/bin` to your path:
+ 1. Open your shell configuration file. This is `~/.bashrc` if you're using a bash shell, or `~/.zshrc` if you're using a zsh shell.
+ 2. Run the following command:
+ ```console
+ $ export PATH=$PATH:~/.docker/bin
+ ```
+ 3. Save and the close the file. Restart your shell to apply the changes to the PATH variable.
+
+- **Enable default Docker socket (Requires password)**. Creates `/var/run/docker.sock` which some third party clients may use to communicate with Docker Desktop. For more information, see [permission requirements for macOS](../mac/permission-requirements.md#installing-symlinks).
+
+- **Enable privileged port mapping (Requires password)**. Starts the privileged helper process which binds the ports that are between 1 and 1024. For more information, see [permission requirements for macOS](../mac/permission-requirements.md#binding-privileged-ports).
+
+For more information on each configuration
+and use case, see [Permission requirements](../mac/permission-requirements.md).
+
## Resources
The **Resources** tab allows you to configure CPU, memory, disk, proxies,
diff --git a/desktop/uninstall.md b/desktop/uninstall.md
index 7037ef5aa7..d3e6dab43c 100644
--- a/desktop/uninstall.md
+++ b/desktop/uninstall.md
@@ -34,7 +34,7 @@ To uninstall Docker Desktop from your Windows machine:
To uninstall Docker Desktop from your Mac:
-1. From the Docker menu, select **Troubleshoot** and then select **Uninstall**.
+1. From the Docker menu, select the **Troubleshoot** icon in the top-right corner of Docker Dashboard and then select **Uninstall**.
2. Click **Uninstall** to confirm your selection.
> Uninstall Docker Desktop from the command line
@@ -160,4 +160,4 @@ Remove the `credsStore` and `currentContext` properties from `$HOME/.docker/conf
-
\ No newline at end of file
+
diff --git a/desktop/use-desktop/container.md b/desktop/use-desktop/container.md
index 9f3904f082..9f2b58ed1b 100644
--- a/desktop/use-desktop/container.md
+++ b/desktop/use-desktop/container.md
@@ -38,7 +38,7 @@ To open the integrated terminal, either:
You can obtain detailed information about the container when you select a container.
-The **container view** displays **Logs**, **Inspect**, **Terminal**, and **Stats** tabs and provides quick action buttons to perform various actions.
+The **container view** displays **Logs**, **Inspect**, **Terminal**, **Files**, and **Stats** tabs and provides quick action buttons to perform various actions.
- Select **Logs** to see logs from the container. You can also:
- Use `Cmd + f`/`Ctrl + f` to open the search bar and find specific entries. Search matches are highlighted in yellow.
@@ -50,4 +50,11 @@ The **container view** displays **Logs**, **Inspect**, **Terminal**, and **Stats
- Select **Inspect** to view low-level information about the container. You can see the local path, version number of the image, SHA-256, port mapping, and other details.
+- Select **Files** to explore the filesystem of running or stopped containers. You can also:
+ - See which files have been recently added, modified, or deleted
+ - Edit a file straight from the built-in editor
+ - Drag and drop files and folders between the host and the container
+ - Delete unnecessary files when you right-click on a file
+ - Download file and folders from the container straight to the host
+
- Select **Stats** to view information about the container resource utilization. You can see the amount of CPU, disk I/O, memory, and network I/O used by the container.
diff --git a/desktop/use-desktop/index.md b/desktop/use-desktop/index.md
index 4abaaf99cd..2ab54c7d48 100644
--- a/desktop/use-desktop/index.md
+++ b/desktop/use-desktop/index.md
@@ -12,7 +12,7 @@ When you open Docker Desktop, the Docker Dashboard displays.
The **Containers** view provides a runtime view of all your containers and applications. It allows you to interact with containers and applications, and manage the lifecycle of your applications directly from your machine. This view also provides an intuitive interface to perform common actions to inspect, interact with, and manage your Docker objects including containers and Docker Compose-based applications. For more information, see [Explore running containers and applications](container.md).
-The **Images** view displays a list of your Docker images and allows you to run an image as a container, pull the latest version of an image from Docker Hub, and inspect images. It also displays a summary of the vulnerability scanning report using Snyk. In addition, the **Images** view contains clean-up options to remove unwanted images from the disk to reclaim space. If you are logged in, you can also see the images you and your organization have shared on Docker Hub. For more information, see [Explore your images](images.md).
+The **Images** view displays a list of your Docker images and allows you to run an image as a container, pull the latest version of an image from Docker Hub, and inspect images. It also displays a summary of image vulnerabilities. In addition, the **Images** view contains clean-up options to remove unwanted images from the disk to reclaim space. If you are logged in, you can also see the images you and your organization have shared on Docker Hub. For more information, see [Explore your images](images.md).
The **Volumes** view displays a list of volumes and allows you to easily create and delete volumes and see which ones are being used. For more information, see [Explore volumes](volumes.md).
@@ -31,7 +31,7 @@ From the Docker Dashboard you can use Quick Search, which is located in the Dash
- Extensions. From here, you can learn more about the extension and install it with a single click. Or, if you already have an extension installed, you can open it straight from the search results.
-- Any volume. From here you can view the associated container.
+- Any volume. From here you can view the associated container.
## The Docker menu
@@ -43,9 +43,9 @@ To display the Docker menu, right-click on the , which inherits constraints like firewall rules, VPN, HTTP proxy properties etc. from the user that launched it.
-
-
-
diff --git a/develop/remote-development.md b/develop/remote-development.md
index 5e7b8037e2..6f248c0850 100644
--- a/develop/remote-development.md
+++ b/develop/remote-development.md
@@ -32,7 +32,7 @@ remote resources helps simplify and speed up the inner loop. There are several
tools available, commercial and open-source, that you can use to enable a hybrid
local-and-remote development environment. For example:
-- [Telepresence](https://www.cncf.io/projects/telepresence/){: target="_blank" rel="noopener" class="_" }
+- [Telepresence](https://app.getambassador.io/auth/realms/production/protocol/openid-connect/auth?client_id=docker-docs&response_type=code&redirect_uri=https%3A%2F%2Fapp.getambassador.io&utm_source=docker-docs&utm_medium=dockerwebsite&utm_campaign=Docker%26TP){: target="_blank" rel="noopener" class="_" }
- [CodeZero](https://www.codezero.io/){: target="_blank" rel="noopener" class="_" }
- [Gefyra](https://gefyra.dev/){: target="_blank" rel="noopener" class="_" }
- [kubefwd](https://kubefwd.com/){: target="_blank" rel="noopener" class="_" }
@@ -72,9 +72,9 @@ You have a few options for how the local containers can integrate with the clust
Telepresence is free and open-source, and you can try it out by heading to
the
-[Telepresence quickstart guide](https://www.telepresence.io/docs/latest/quick-start/){: target="_blank" rel="noopener" class="_" }.
+[Telepresence quickstart guide](https://www.telepresence.io/docs/latest/quick-start/?utm_source=docker-docs&utm_medium=dockerwebsite&utm_campaign=Docker-TP){: target="_blank" rel="noopener" class="_" }.
There’s also a
-[Telepresence extension for Docker Desktop](https://www.getambassador.io/docs/telepresence/latest/extension/intro){: target="_blank" rel="noopener" class="_" },
+[Telepresence extension for Docker Desktop](https://www.getambassador.io/docs/telepresence/latest/extension/intro?utm_source=docker-docs&utm_medium=dockerwebsite&utm_campaign=Docker-TP){: target="_blank" rel="noopener" class="_" },
which helps you manage intercepts for your containers.
### Docker × Ambassador
@@ -92,7 +92,7 @@ local-remote development environment easy and seamless. You can now connect your
Docker ID to Ambassador Cloud to sign in and use Telepresence. To get started:
1. Go to the
- [Docker × Ambassador](https://app.getambassador.io/auth/realms/production/protocol/openid-connect/auth?client_id=docker-docs&response_type=code&redirect_uri=https://app.getambassador.io)
+ [Docker × Ambassador](https://app.getambassador.io/auth/realms/production/protocol/openid-connect/auth?client_id=docker-docs&response_type=code&redirect_uri=https%3A%2F%2Fapp.getambassador.io&utm_source=docker-docs&utm_medium=dockerwebsite&utm_campaign=Docker%26TP)
page.
2. Sign in using your Docker ID.
3. Authorize the Ambassador Cloud app.
diff --git a/docker-hub/2fa/disable-2fa.md b/docker-hub/2fa/disable-2fa.md
index 2b5c8bcc07..2e6c51bc22 100644
--- a/docker-hub/2fa/disable-2fa.md
+++ b/docker-hub/2fa/disable-2fa.md
@@ -4,25 +4,16 @@ keywords: Docker, docker, registry, security, Docker Hub, authentication, two-fa
title: Disable two-factor authentication on Docker Hub
---
-> **Note:**
-> Disabling two-factor authentication will result in decreased security for your
+> **Warning**
+>
+> Disabling two-factor authentication results in decreased security for your
> Docker Hub account.
{: .warning }
-
-## Prerequisites
-Two-factor authentication is enabled on your Docker Hub account.
-
## Disable two-factor authentication
-To disable two-factor authentication, log in to your Docker Hub account. Click
-on your username and select **Account Settings**. Go to Security and click on
-**Disable 2FA**.
+1. Sign in to your Docker Hub account.
+2. Select your username and then from the dropdown menu, select **Account Settings**.
+3. Navigate to the **Security** tab and select **Disable 2FA**.
+4. Enter your password and select **Disable 2FA**.
-
-You will be prompted to input your Docker ID password. Enter your password and
-click **Disable 2FA**.
-
-{:width="250px"}
-
-You have successfully disabled two-factor authentication.
diff --git a/docker-hub/2fa/index.md b/docker-hub/2fa/index.md
index 40a70a4f70..16600a6004 100644
--- a/docker-hub/2fa/index.md
+++ b/docker-hub/2fa/index.md
@@ -4,12 +4,11 @@ keywords: Docker, docker, registry, security, Docker Hub, authentication, two-fa
title: Enable two-factor authentication for Docker Hub
---
-## About two-factor authentication
Two-factor authentication adds an extra layer of security to your Docker Hub
-account by requiring a unique security code when you log into your account. The
-security code will be required in addition to your password.
+account by requiring a unique security code when you sign in to your account. The
+security code is required in addition to your password.
-When you enable two-factor authentication, you will also be provided a recovery
+When you enable two-factor authentication, you are also provided with a recovery
code. Each recovery code is unique and specific to your account. You can use
this code to recover your account in case you lose access to your authenticator
app. See [Recover your Docker Hub account](recover-hub-account/).
@@ -21,45 +20,20 @@ You need a mobile phone with a time-based one-time password authenticator
application installed. Common examples include Google Authenticator or Yubico
Authenticator with a registered YubiKey.
-> **Note:**
-> Two-factor authentication is currently in beta. Feel free to provide feedback
-> at the [Docker Hub feedback repo](https://github.com/docker/hub-feedback/issues).
-{: .important}
-
## Enable two-factor authentication
-To enable two-factor authentication, log in to your Docker Hub account. Click
-on your username and select **Account Settings**. Go to Security and click
-**Enable Two-Factor Authentication**.
+1. Sign to your Docker Hub account.
+2. Select your username and then from the dropdown menu, select **Account Settings**.
+3. Select the **Security** tab and then select **Enable Two-Factor Authentication**.
+ The next page reminds you to download an authenticator app.
+4. Select **Set up using an app**.
+ Your unique recovery code is sent to you.
+5. Save your recovery code and store it somewhere safe.
+ Your recovery code can be used to recover your account in the event you lose access to your authenticator app.
-
+6. Select **Next** and then open your authenticator app.
+ You can choose between scanning the QR code or entering a text code into your authenticator app.
+7. Once you have linked your authenticator app, enter the six-digit code to in text field and then select **Next**.
-The next page will remind you to download an authenticator app. Click **Set up**
-**using an app**. You will receive your unique recovery code.
-
-> **Save your recovery code and store it somewhere safe.**
->
-> Your recovery code can be used to recover your account in the event you lose
-> access to your authenticator app.
-{: .important }
-
-
-
-After you have saved your code, click **Next**.
-
-Open your authenticator app. You can choose between scanning the QR code or
-entering a text code into your authenticator app. Once you have linked your
-authenticator app, it will give you a six-digit code to enter in text field.
-Click **Next**.
-
-
-
-You have successfully enabled two-factor authentication. The next time you log
+Two-factor authentication is now enabled. The next time you sign
in to your Docker Hub account, you will be asked for a security code.
-
-> **Note:**
-> Now that you have two-factor authentication enabled on your account, you must
-> create at least one personal access token. Otherwise, you will be unable to
-> log in to your account from the Docker CLI. See [Managing access tokens](../access-tokens)
-> for more information.
-{: .important }
diff --git a/docker-hub/2fa/new-recovery-code.md b/docker-hub/2fa/new-recovery-code.md
index 9c1f5142a1..d5431dc018 100644
--- a/docker-hub/2fa/new-recovery-code.md
+++ b/docker-hub/2fa/new-recovery-code.md
@@ -7,20 +7,12 @@ title: Generate a new recovery code
If you have lost your two-factor authentication recovery code and still have
access to your Docker Hub account, you can generate a new recovery code.
-## Prerequisites
-
-Two-factor authentication is enabled on your Docker Hub account.
-
## Generate a new recovery code
-To disable two-factor authentication, log in to your Docker Hub account. Click
-on your username and select **Account Settings**. Go to **Security** and **Click here to generate a new code**.
+1. Sign in to your Docker Hub account.
+2. Select your username and then from the dropdown menu, select **Account Settings**.
+3. Navigate to the **Security** tab and select **Click here to generate a new code**.
+4. Enter your password.
-
-
-Enter your password.
-
-{:width="250px"}
-
-Your new recovery code will be displayed. Remember to save your recovery code
+Your new recovery code is displayed. Remember to save your recovery code
and store it somewhere safe.
diff --git a/docker-hub/2fa/recover-hub-account.md b/docker-hub/2fa/recover-hub-account.md
index fc4bc5271b..1c544f4754 100644
--- a/docker-hub/2fa/recover-hub-account.md
+++ b/docker-hub/2fa/recover-hub-account.md
@@ -5,9 +5,9 @@ title: Recover your Docker Hub account
---
-If you have lost access to both your two-factor authentication application and
-your recovery code,
+If you have lost access to both your two-factor authentication application and your recovery code:
1. Navigate to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"} and enter your username and password.
-2. Click **I've lost my authentication device** and **I've lost my recovery code**.
-3. Complete the [Contact Support form](https://hub.docker.com/support/contact/?category=2fa-lockout){:target="_blank" rel="noopener" class="_"}. You must enter the primary email address associated with your Docker ID in the Contact Support form for recovery instructions.
+2. Select **I've lost my authentication device** and **I've lost my recovery code**.
+3. Complete the [Contact Support form](https://hub.docker.com/support/contact/?category=2fa-lockout){:target="_blank" rel="noopener" class="_"}.
+ You must enter the primary email address associated with your Docker ID in the Contact Support form for recovery instructions.
diff --git a/docker-hub/access-tokens.md b/docker-hub/access-tokens.md
index 82a5334162..b2214e7b10 100644
--- a/docker-hub/access-tokens.md
+++ b/docker-hub/access-tokens.md
@@ -1,67 +1,49 @@
---
-title: Manage access tokens
+title: Create and manage access tokens
description: Learn how to create and manage your personal Docker Hub access tokens to securely push and pull images programmatically.
keywords: docker hub, hub, security, PAT, personal access token
---
-Docker Hub lets you create personal access tokens as alternatives to your password. You can use tokens to access Hub images from the Docker CLI.
+If you are using the [Docker Hub CLI](https://github.com/docker/hub-tool#readme){: target="_blank" rel="noopener" class="_"}
+tool (currently experimental) to access Hub images from the Docker CLI, you can create personal access tokens (PAT) as alternatives to your password.
-Using personal access tokens provides some advantages over a password:
+Compared to passwords, personal access tokens provide the following advantages:
-* You can investigate the last usage of the access token and disable or delete
- it if you find any suspicious activity.
-* When using an access token, you can't perform any admin activity on the account, including changing the password. It protects your account if your computer is compromised.
+- You can investigate when the PAT was last used and then disable or delete it if you find any suspicious activity.
+- When using an access token, you can't perform any admin activity on the account, including changing the password. It protects your account if your computer is compromised.
-Docker provides a [Docker Hub CLI](https://github.com/docker/hub-tool#readme){: target="_blank" rel="noopener" class="_"}
-tool (currently experimental) and an API that allows you to interact with Docker Hub. Browse through the [Docker Hub API](/docker-hub/api/latest/){: target="_blank" rel="noopener" class="_"} documentation to explore the supported endpoints.
-
-> **Important**
->
-> Treat access tokens like your password and keep them secret. Store your
-> tokens securely (for example, in a credential manager).
-{: .important}
-
-Access tokens are valuable for building integrations, as you can issue
-multiple tokens – one for each integration – and revoke them at
+Access tokens are also valuable for building integrations, as you can issue multiple tokens, one for each integration, and revoke them at
any time.
-
> **Note**
>
> If you have [two-factor authentication (2FA)](2fa/index.md) enabled on
> your account, you must create at least one personal access token. Otherwise,
- > you will be unable to log in to your account from the Docker CLI.
-
+ > you won't be able to sign in to your account from the Docker CLI.
## Create an access token
-The following video walks you through the process of managing access tokens.
+> **Important**
+>
+> Treat access tokens like your password and keep them secret. Store your tokens securely in a credential manager for example.
+{: .important}
-
+1. Sign in to [Docker Hub](https://hub.docker.com){: target="_blank" rel="noopener" class="_"}.
-To create your access token:
+2. Select your username in the top-right corner and from the dropdown menu select **Account Settings**.
-1. Log in to [hub.docker.com](https://hub.docker.com){: target="_blank" rel="noopener" class="_"}.
-
-2. Click on your username in the top right corner and select **[Account Settings](https://hub.docker.com/settings/general)**.
-
-3. Select **[Security](https://hub.docker.com/settings/security) > New Access Token**.
-
-4. Add a description for your token. Use something that indicates where the token
- will be used, or set a purpose for the token. You can view the following access
- permissions from the drop-down:
-
- {:width="700px"}
+3. Select the **Security** tab and then **New Access Token**.
+4. Add a description for your token. Use something that indicates the use case or purpose of the token.
+
+5. Set the access permissions.
The access permissions are scopes that set restrictions in your
repositories. For example, for Read & Write permissions, an automation
pipeline can build an image and then push it to a repository. However, it
can not delete the repository.
-5. Copy the token that appears on the screen and save it. You will not be able
+6. Select **Generate** and then copy the token that appears on the screen and save it. You won't be able
to retrieve the token once you close this prompt.
- {:width="700px"}
-
## Use an access token
You can use an access token anywhere that requires your Docker Hub
@@ -81,16 +63,11 @@ a password.
You can rename, activate, deactivate, or delete a token as needed.
-1. Access your tokens under **[Account Settings > Security](https://hub.docker.com/settings/security){: target="_blank" rel="noopener" class="_"}**.
+1. Access your tokens under **Account Settings > Security**.
This page shows an overview of all your tokens. You can also view the number
of tokens that are activated and deactivated in the toolbar.
- {:width="700px"}
+2. Choose a token and then select **Delete** or **Edit**, or use the menu on the far right of a token row to bring up the edit screen.
+ You can also select multiple tokens to delete at once.
-2. Select a token and click **Delete** or **Edit**, or use the menu on
- the far right of a token row to bring up the edit screen. You can also
- select multiple tokens to delete at once.
-
- {:width="700px"}
-
-3. After modifying the token, click the **Save** button to save your changes.
+3. After modifying the token, select **Save**.
diff --git a/docker-hub/admin-overview.md b/docker-hub/admin-overview.md
new file mode 100644
index 0000000000..6f5f0a29f2
--- /dev/null
+++ b/docker-hub/admin-overview.md
@@ -0,0 +1,70 @@
+---
+title: Administration
+description: landing page for administration topic
+keywords: administration, docker hub, admin
+---
+
+Sign in to Docker Hub to change account settings and carry out administrative or security-related tasks.
+
+
+
+
+
+
+
+
+
+
+
+
+
Explore the security model for Docker Desktop.
+
+
+
+
+
+
+
+
+
+
+
+
Configure sign in for members of your teams and organizations.
+
+
+
+
+
+
+
+
+
Understand and use Single Sign-On.
+
+
+
+
+
+
+
+
+
Add an extra layer of authentication to your Docker account.
+
+
+
+
diff --git a/docker-hub/audit-log.md b/docker-hub/audit-log.md
index f2bc71b20c..737054d2eb 100644
--- a/docker-hub/audit-log.md
+++ b/docker-hub/audit-log.md
@@ -4,30 +4,33 @@ keywords: Team, organization, activity, log, audit, activities
title: Audit logs
---
-{% include upgrade-cta.html
- body="Audit logs are available for users subscribed to a Docker Team or a Business subscription. Upgrade now to start tracking events across your organization."
- header-text="This feature requires a paid Docker subscription"
- target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_audit_log"
-%}
+> **Note**
+>
+> Audit logs requires a [Docker Team, or Business subscription](../subscription/index.md).
-Audit logs display a chronological list of activities that occur at organization and repository levels. It provides owners of Docker Team accounts a report of all their team member activities. This allows the team owners to view and track what changes were made, the date when a change was made, and who initiated the change. For example, the audit logs display activities such as the date when a repository was created or deleted, the team member who created the repository, the name of the repository, and when there was a change to the privacy settings.
+Audit logs display a chronological list of activities that occur at organization and repository levels. It provides a report to owners of Docker Team on all their team member activities.
+
+With audit logs, team owners can view and track:
+ - What changes were made
+ - The date when a change was made
+ - Who initiated the change
+
+ For example, Audit logs display activities such as the date when a repository was created or deleted, the team member who created the repository, the name of the repository, and when there was a change to the privacy settings.
Team owners can also see the audit logs for their repository if the repository is part of the organization subscribed to a Docker Team plan.
+Audit logs began tracking activities from the date the feature went live, that is from 25 January 2021. Activities that took place before this date are not captured.
+
## View the audit logs
To view the audit logs:
-1. Sign into an owner account for the organization in Docker Hub.
-2. Select your organization from the list and then click on the **Activity** tab.
-
- {:width="700px"}
-
-The audit logs begin tracking activities from the date the feature is live, that is from **25 January 2021**. Activities that took place before this date are not captured.
+1. Sign in to Docker Hub.
+2. Select your organization from the list and then select the **Activity** tab.
> **Note**
>
-> Docker will retain the activity data for a period of three months.
+> Docker retains the activity data for a period of three months.
## Customize the audit logs
@@ -39,10 +42,9 @@ By default, all activities that occur at organization and repository levels are
>
> Activities created by the Docker Support team as part of resolving customer issues appear in the audit logs as **dockersupport**.
-Click the **All Activities** drop-down list to view activities that are specific to an organization or a repository. After choosing **Organization** or **Repository**, you can further refine the results using the **All Actions** drop-down list. If you select the **Activities** tab from the **Repository** view, you can only filter repository-level activities.
-
-{:width="600px"}
+Select the **All Activities** dropdown to view activities that are specific to an organization, repository, or billing. If you select the **Activities** tab from the **Repository** view, you can only filter repository-level activities.
+After choosing **Organization**, **Repository**, or **Billing**, you can further refine the results using the **All Actions** dropdown.
## Audit logs event definitions
diff --git a/docker-hub/builds/advanced.md b/docker-hub/builds/advanced.md
index 112e063ef1..d508fca7dc 100644
--- a/docker-hub/builds/advanced.md
+++ b/docker-hub/builds/advanced.md
@@ -6,11 +6,10 @@ redirect_from:
- /docker-cloud/builds/advanced/
---
-{% include upgrade-cta.html
- body="The Automated Builds feature is available for Docker Pro, Team, and Business users. Upgrade now to automatically build and push your images. If you are using automated builds for an open-source project, you can join our [Open Source Community](https://www.docker.com/community/open-source/application){: target='_blank' rel='noopener' class='_'} program to learn how Docker can support your project on Docker Hub."
- header-text="This feature requires a Docker subscription"
- target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_auto_builds"
-%}
+> **Note**
+>
+> Automated builds require a
+> [Docker Pro, Team, or Business subscription](../../subscription/index.md).
The following options allow you to customize your automated build and automated
test processes.
@@ -21,8 +20,10 @@ Several utility environment variables are set by the build process, and are
available during automated builds, automated tests, and while executing
hooks.
-> **Note**: These environment variables are only available to the build and test
-processes and do not affect your service's run environment.
+> **Note**
+>
+> These environment variables are only available to the build and test
+processes and don't affect your service's run environment.
* `SOURCE_BRANCH`: the name of the branch or the tag that is currently being tested.
* `SOURCE_COMMIT`: the SHA1 hash of the commit being tested.
@@ -51,12 +52,15 @@ services:
Docker Hub allows you to override and customize the `build`, `test` and `push`
commands during automated build and test processes using hooks. For example, you
might use a build hook to set build arguments used only during the build
-process. (You can also set up [custom build phase hooks](#custom-build-phase-hooks)
-to perform actions in between these commands.)
+process. You can also set up [custom build phase hooks](#custom-build-phase-hooks)
+to perform actions in between these commands.
-**Use these hooks with caution.** The contents of these hook files replace the
+> **Important**
+>
+>Use these hooks with caution. The contents of these hook files replace the
basic `docker` commands, so you must include a similar build, test or push
command in the hook or your automated process does not complete.
+{: .important}
To override these phases, create a folder called `hooks` in your source code
repository at the same directory level as your Dockerfile. Create a file called
@@ -64,7 +68,7 @@ repository at the same directory level as your Dockerfile. Create a file called
builder process can execute, such as `docker` and `bash` commands (prefixed
appropriately with `#!/bin/bash`).
-These hooks will be running on an instance of [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/){:target="_blank" rel="noopener" class="_"},
+These hooks run on an instance of [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/){:target="_blank" rel="noopener" class="_"},
a distro based on Red Hat Enterprise Linux (RHEL), which includes interpreters
such as Perl or Python, and utilities such as `git` or `curl`. Refer to the
[Amazon Linux 2 documentation](https://aws.amazon.com/amazon-linux-2/faqs/){:target="_blank" rel="noopener" class="_"}
@@ -89,15 +93,15 @@ The following hooks are available:
* `hooks/post_build`
* `hooks/pre_test`
* `hooks/post_test`
-* `hooks/pre_push` (only used when executing a build rule or [automated build](index.md) )
-* `hooks/post_push` (only used when executing a build rule or [automated build](index.md) )
+* `hooks/pre_push` (only used when executing a build rule or [Automated build](index.md) )
+* `hooks/post_push` (only used when executing a build rule or [Automated build](index.md) )
### Build hook examples
#### Override the "build" phase to set variables
Docker Hub allows you to define build environment variables either in the hook
-files, or from the automated build interface (which you can then reference in hooks).
+files, or from the automated build interface, which you can then reference in hooks.
In the following example, we define a build hook that uses `docker build` arguments
to set the variable `CUSTOM` based on the value of variable we defined using the
@@ -109,9 +113,11 @@ the image being built.
$ docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME .
```
-> **Caution**: A `hooks/build` file overrides the basic [docker build](../../engine/reference/commandline/build.md) command
-used by the builder, so you must include a similar build command in the hook or
+> **Important**
+>
+> A `hooks/build` file overrides the basic [docker build](../../engine/reference/commandline/build.md) command used by the builder, so you must include a similar build command in the hook or
the automated build fails.
+{: .important}
Refer to the [docker build documentation](../../engine/reference/commandline/build.md#build-arg)
to learn more about Docker build-time variables.
@@ -128,15 +134,15 @@ $ docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT
$ docker push $DOCKER_REPO:$SOURCE_COMMIT
```
-## Source Repository / Branch Clones
+## Source repository or branch clones
When Docker Hub pulls a branch from a source code repository, it performs
-a shallow clone (only the tip of the specified branch). This has the advantage
+a shallow clone, it clones only the tip of the specified branch. This has the advantage
of minimizing the amount of data transfer necessary from the repository and
speeding up the build because it pulls only the minimal code necessary.
-Because of this, if you need to perform a custom action that relies on a different
-branch (such as a `post_push` hook), you can't checkout that branch, unless
+As a result, if you need to perform a custom action that relies on a different
+branch, such as a `post_push` hook, you can't checkout that branch unless
you do one of the following:
* You can get a shallow checkout of the target branch by doing the following:
diff --git a/docker-hub/builds/automated-testing.md b/docker-hub/builds/automated-testing.md
index 49fd00937c..f0fdd1e928 100644
--- a/docker-hub/builds/automated-testing.md
+++ b/docker-hub/builds/automated-testing.md
@@ -7,18 +7,17 @@ redirect_from:
title: Automated repository tests
---
-{% include upgrade-cta.html
- body="The Automated Builds feature is available for Docker Pro, Team, and Business users. Upgrade now to automatically build and push your images. If you are using automated builds for an open-source project, you can join our [Open Source Community](https://www.docker.com/community/open-source/application){: target='_blank' rel='noopener' class='_'} program to learn how Docker can support your project on Docker Hub."
- header-text="This feature requires a Docker subscription"
- target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_auto_builds"
-%}
+> **Note**
+>
+> Automated builds require a
+> [Docker Pro, Team, or Business subscription](../../subscription/index.md).
Docker Hub can automatically test changes to your source code repositories
using containers. You can enable `Autotest` on [any Docker Hub repository](../repos/index.md)
to run tests on each pull request to the source code repository to create a
continuous integration testing service.
-Enabling `Autotest` builds an image for testing purposes, but does **not**
+Enabling `Autotest` builds an image for testing purposes, but does not
automatically push the built image to the Docker repository. If you want to push
built images to your Docker Hub repository, enable [Automated Builds](index.md).
@@ -43,28 +42,27 @@ a container using the built image.
You can define any number of linked services in this file. The only requirement
is that `sut` is defined. Its return code determines if tests passed or not.
-Tests **pass** if the `sut` service returns `0`, and **fail** otherwise.
+Tests pass if the `sut` service returns `0`, and fail otherwise.
> **Note**
>
> Only the `sut` service and all other services listed in
-> [`depends_on`](../../compose/compose-file/compose-file-v2.md#depends_on) are
+> [`depends_on`](../../compose/compose-file/05-services.md#depends_on) are
> started. If you have services that poll for changes in other services, be sure
-> to include the polling services in the [`depends_on`](../../compose/compose-file/compose-file-v2.md#depends_on)
+> to include the polling services in the [`depends_on`](../../compose/compose-file/05-services.md#depends_on)
> list to make sure all of your services start.
-> Also make sure to include a compose file version from 2.0 upward as `depends_on`
-> was added in [version 2.0](../../compose/compose-file/compose-versioning.md#version-2)
-> file format.
You can define more than one `docker-compose.test.yml` file if needed. Any file
that ends in `.test.yml` is used for testing, and the tests run sequentially.
You can also use [custom build hooks](advanced.md#override-build-test-or-push-commands)
to further customize your test behavior.
-> **Note**: If you enable Automated builds, they also run any tests defined
+> **Note**
+>
+> If you enable Automated builds, they also run any tests defined
in the `test.yml` files.
-## Enable automated tests on a repository
+## Enable Automated tests on a repository
To enable testing on a source code repository, you must first create an
associated build-repository in Docker Hub. Your `Autotest` settings are
@@ -72,24 +70,24 @@ configured on the same page as [automated builds](index.md), however
you do not need to enable Autobuilds to use `Autotest`. Autobuild is enabled per
branch or tag, and you do not need to enable it at all.
-Only branches that are configured to use **Autobuild** push images to the
+Only branches that are configured to use Autobuild push images to the
Docker repository, regardless of the Autotest settings.
-1. Log in to Docker Hub and select **Repositories** in the top navigation.
+1. Sign in to Docker Hub and select **Repositories**.
2. Select the repository you want to enable `Autotest` on.
-3. From the repository view, click the **Builds** tab.
+3. From the repository view, select the **Builds** tab.
-4. Click **Configure automated builds**.
+4. Select **Configure automated builds**.
5. Configure the automated build settings as explained in [Automated Builds](index.md).
At minimum you must configure:
* The source code repository
- * the build location
- * at least one build rule
+ * The build location
+ * At least one build rule
6. Choose your **Autotest** option.
@@ -106,19 +104,22 @@ Docker repository, regardless of the Autotest settings.
pull requests to branches that match a build rule, including when the
pull request originated in an external source repository.
- > **Note**: For security purposes, autotest on _external pull requests_ is
+ > **Important**
+ >
+ >For security purposes, autotest on external pull requests is
limited on public repositories. Private images are not pulled and
environment variables defined in Docker Hub are not
available. Automated builds continue to work as usual.
+ {: .important}
-7. Click **Save** to save the settings, or click **Save and build** to save and
+7. Select **Save** to save the settings, or select **Save and build** to save and
run an initial test.
## Check your test results
-From the repository's details page, click **Timeline**.
+From the repository's details page, select **Timeline**.
From this tab you can see any pending, in-progress, successful, and failed
builds and test runs for the repository.
-You can click any timeline entry to view the logs for each test run.
+You can choose any timeline entry to view the logs for each test run.
diff --git a/docker-hub/builds/how-builds-work.md b/docker-hub/builds/how-builds-work.md
new file mode 100644
index 0000000000..7176bf0a00
--- /dev/null
+++ b/docker-hub/builds/how-builds-work.md
@@ -0,0 +1,41 @@
+---
+description: how automated builds work
+keywords: docker hub, automated builds
+title: How Automated builds work
+---
+
+> **Note**
+>
+> Automated builds require a
+> [Docker Pro, Team, or Business subscription](../../subscription/index.md).
+
+Docker Hub can automatically build images from source code in an external
+repository and automatically push the built image to your Docker repositories.
+
+{:width="750px"}
+
+When you set up Automated builds, also called autobuilds, you create a list of
+branches and tags that you want to build into Docker images. When you push code
+to a source-code branch, for example in GitHub, for one of those listed image
+tags, the push uses a webhook to trigger a new build, which produces a Docker
+image. The built image is then pushed to Docker Hub.
+
+> **Note**
+>
+> You can still use `docker push` to push pre-built images to
+repositories with Automated builds configured.
+
+If you have automated tests configured, these run after building but before
+pushing to the registry. You can use these tests to create a continuous
+integration workflow where a build that fails its tests doesn't push the built
+image. Automated tests don't push images to the registry on their own. [Learn about automated image testing](automated-testing.md).
+
+Depending on your [subscription](https://www.docker.com/pricing){: target="_blank" rel="noopener" class="_"},
+you may get concurrent builds, which means that `N` autobuilds can be run at the
+same time. `N` is configured according to your subscription. Once `N+1` builds
+are running, any additional builds go into a queue to be run later.
+
+The maximum number of pending builds in the queue is 30 and Docker Hub discards further
+requests. The number of concurrent builds for Pro is 5 and
+for Team and Business is 15.
+
diff --git a/docker-hub/builds/index.md b/docker-hub/builds/index.md
index 7b91a099fc..2c3e67bf11 100644
--- a/docker-hub/builds/index.md
+++ b/docker-hub/builds/index.md
@@ -1,5 +1,5 @@
---
-description: Set up automated builds
+description: Set up Automated builds
keywords: automated, build, images, Docker Hub
redirect_from:
- /docker-hub/builds/automated-build/
@@ -10,59 +10,28 @@ redirect_from:
title: Set up Automated Builds
---
-{% include upgrade-cta.html
- body="The Automated Builds feature is available for Docker Pro, Team, and Business users. Upgrade now to automatically build and push your images. If you are using automated builds for an open-source project, you can join our [Open Source Community](https://www.docker.com/community/open-source/application){: target='_blank' rel='noopener' class='_'} program to learn how Docker can support your project on Docker Hub."
- header-text="This feature requires a Docker subscription"
- target-url="https://www.docker.com/pricing?utm_source=docker&utm_medium=webreferral&utm_campaign=docs_driven_upgrade_auto_builds"
-%}
-
-## How Automated Builds work
-
-Docker Hub can automatically build images from source code in an external
-repository and automatically push the built image to your Docker repositories.
-
-When you set up automated builds (also called autobuilds), you create a list of
-branches and tags that you want to build into Docker images. When you push code
-to a source code branch (for example in GitHub) for one of those listed image
-tags, the push uses a webhook to trigger a new build, which produces a Docker
-image. The built image is then pushed to the Docker Hub registry.
-
> **Note**
>
-> You can still use `docker push` to push pre-built images to
-repositories with Automated Builds configured.
+> Automated builds require a
+> [Docker Pro, Team, or Business subscription](../../subscription/index.md).
-If you have automated tests configured, these run after building but before
-pushing to the registry. You can use these tests to create a continuous
-integration workflow where a build that fails its tests doesn't push the built
-image. Automated tests don't push images to the registry on their own. [Learn about automated image testing](automated-testing.md).
+This page contains information on:
+- [Configuring Automated builds](#configure-automated-builds)
+- [Advanced Automated build options](#advanced-automated-build-options)
+- [Automated builds for teams](#autobuild-for-teams)
-Depending on your [subscription](https://www.docker.com/pricing){: target="_blank" rel="noopener" class="_"},
-you may get concurrent builds, which means that `N` autobuilds can be run at the
-same time. `N` is configured according to your subscription. Once `N+1` builds
-are running, any additional builds go into a queue to be run later.
-
-The maximum number of pending builds in the queue is 30 and Docker Hub discards further
-requests. The number of concurrent builds for Pro is 5 and
-for Team and Business is 15.
-
-
-
-## Configure automated build settings
+## Configure Automated builds
You can configure repositories in Docker Hub so that they automatically
build an image each time you push new code to your source provider. If you have
[automated tests](automated-testing.md) configured, the new image is only pushed
when the tests succeed.
-You can add builds to existing repositories, or add them when you create a repository.
-
1. From the **Repositories** section, select a repository to view its details.
2. Select the **Builds** tab.
-3. If you are setting up automated builds for the first time, select the code
- repository service (GitHub or Bitbucket) where the image's source code is stored.
+3. Select either GitHub or Bitbucket to connect where the image's source code is stored.
> Note
>
@@ -73,31 +42,32 @@ You can add builds to existing repositories, or add them when you create a repos
4. Select the **source repository** to build the Docker images from.
> Note
- > You might need to specify an organization or user (the _namespace_) from
- > the source code provider. Once you select a namespace, its source code
+ > You might need to specify an organization or user from
+ > the source code provider. Once you select a user, source code
> repositories appear in the **Select repository** dropdown list.
-5. Optionally, enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository).
+5. Optional: Enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository).
-6. Review the default **Build Rules**, and optionally select the
- **plus sign** to add and configure more build rules.
+6. Review the default **Build Rules**
- _Build rules_ control what Docker Hub builds into images from the contents
+ Build rules control what Docker Hub builds into images from the contents
of the source code repository, and how the resulting images are tagged
within the Docker repository.
A default build rule is set up for you, which you can edit or delete. This
- default set builds from the `Branch` in your source code repository called
- `master`, and creates a Docker image tagged with `latest`.
+ default rule sets builds from the `Branch` in your source code repository called
+ `master` or `main`, and creates a Docker image tagged with `latest`. For more information, see [set up build rules](#set-up-build-rules)
-7. For each branch or tag, enable or disable the **Autobuild** toggle.
+7. Optional: Select the **plus** icon to add and [configure more build rules](#set-up-build-rules).
+
+8. For each branch or tag, enable or disable the **Autobuild** toggle.
Only branches or tags with autobuild enabled are built, tested, and have
the resulting image pushed to the repository. Branches with autobuild
disabled are built for test purposes (if enabled at the repository
level), but the built Docker image isn't pushed to the repository.
-8. For each branch or tag, enable or disable the **Build Caching** toggle.
+9. For each branch or tag, enable or disable the **Build Caching** toggle.
[Build caching](../../develop/develop-images/dockerfile_best-practices.md#leverage-build-cache)
can save time if you are building a large image frequently or have
@@ -105,20 +75,20 @@ You can add builds to existing repositories, or add them when you create a repos
make sure all of your dependencies are resolved at build time, or if
you have a large layer that's quicker to build locally.
-9. Click **Save** to save the settings, or click **Save and build** to save and
+10. Select **Save** to save the settings, or select **Save and build** to save and
run an initial test.
> Note
>
> A webhook is automatically added to your source code repository to notify
- > Docker Hub on every push. Only pushes to branches that's listed as the
- > source for one or more tags trigger a build.
+ > Docker Hub on every push. Only pushes to branches that are listed as the
+ > source for one or more tags, trigger a build.
### Set up build rules
-By default when you set up automated builds, a basic build rule is created for you.
-This default rule watches for changes to the `master` branch in your source code
-repository, and builds the `master` branch into a Docker image tagged with
+By default when you set up Automated builds, a basic build rule is created for you.
+This default rule watches for changes to the `master` or `main` branch in your source code
+repository, and builds the `master` or `main` branch into a Docker image tagged with
`latest`.
In the **Build Rules** section, enter one or more sources to build.
@@ -130,34 +100,34 @@ For each source:
* Enter the name of the **Source** branch or tag you want to build.
- The first time you configure automated builds, a default build rule is set up
+ The first time you configure Automated builds, a default build rule is set up
for you. This default set builds from the `Branch` in your source code called
`master`, and creates a Docker image tagged with `latest`.
You can also use a regex to select which source branches or tags to build.
To learn more, see
- [regexes](index.md#regexes-and-automated-builds).
+ [regexes](#regexes-and-automated-builds).
* Enter the tag to apply to Docker images built from this source.
If you configured a regex to select the source, you can reference the
capture groups and use its result as part of the tag. To learn more, see
- [regexes](index.md#regexes-and-automated-builds).
+ [regexes](#regexes-and-automated-builds).
* Specify the **Dockerfile location** as a path relative to the root of the source code repository. If the Dockerfile is at the repository root, leave this path set to `/`.
> **Note**
>
> When Docker Hub pulls a branch from a source code repository, it performs a
-> shallow clone (only the tip of the specified branch). Refer to
-> [Advanced options for Autobuild and Autotest](advanced.md#source-repository--branch-clones)
+> shallow clone - only the tip of the specified branch. Refer to
+> [Advanced options for Autobuild and Autotest](advanced.md#source-repository-or-branch-clones)
> for more information.
### Environment variables for builds
You can set the values for environment variables used in your build processes
when you configure an automated build. Add your build environment variables by
-clicking the plus sign next to the **Build environment variables** section, and
+selecting the **plus** icon next to the **Build environment variables** section, and
then entering a variable name and the value.
When you set variable values from the Docker Hub UI, you can use them by the
@@ -169,99 +139,29 @@ should remain secret.
>
> The variables set on the build configuration screen are used during
> the build processes only and shouldn't get confused with the environment
-> values used by your service (for example to create service links).
-
-## Check your active builds
-
-A summary of a repository's builds appears both on the repository **General**
-tab, and in the **Builds** tab. The **Builds** tab also displays a color coded
-bar chart of the build queue times and durations. Both views display the
-pending, in progress, successful, and failed builds for any tag of the
-repository.
-
-
-
-From either location, you can select a build job to view its build report. The
-build report shows information about the build job. This includes the source
-repository and branch (or tag), the build logs, the build duration, creation time and location, and the user namespace the build occurred in.
-
->**Note**
->
-> You can now view the progress of your builds every 30 seconds when you
-> refresh the Builds page. With the in-progress build logs, you can debug your
-> builds before they're finished.
-
-
-
-## Cancel or retry a build
-
-While a build is in queue or running, a **Cancel** icon appears next to its build
-report link on the General tab and on the Builds tab. You can also click the
-**Cancel** on the build report page, or from the Timeline tab's logs
-display for the build.
-
-
-
-## Failing builds
-
-If a build fails, a **Retry** icon appears next to the build report line on the
-**General** and **Builds** tabs. The **Build report** page and **Timeline logs** also display a **Retry** button.
-
-
-
-> **Note**
->
-> If you are viewing the build details for a repository that belongs to an
-> Organization, the Cancel and Retry buttons only appear if you have `Read & Write` access to the repository.
-
-Automated builds have a 4-hour execution time limit. If a build reaches this time limit, it's
-automatically cancelled, and the build logs display the following message:
-
-```text
-2022-11-02T17:42:27Z The build was cancelled or exceeded the maximum execution time.
-```
-
-This log message is the same as when you actively cancel a build. To identify
-whether a build was automatically cancelled, check the build duration.
-
-## Disable an automated build
-
-Automated builds are enabled per branch or tag, and can be disabled and
-re-enabled. You might do this when you want to only build manually for
-a while, for example when you are doing major refactoring in your code. When you disable autobuilds doesn't disable [autotests](automated-testing.md).
-
-To disable an automated build:
-
-1. From the **Repositories** page, select a repository, and select the **Builds** tab.
-
-2. Click **Configure automated builds** to edit the repository's build settings.
-
-3. In the **Build Rules** section, locate the branch or tag you no longer want
-to automatically build.
-
-4. Click the **autobuild** toggle next to the configuration line. When disabled the toggle is gray.
-
-5. Click **Save** to save your changes.
+> values used by your service, for example to create service links.
## Advanced automated build options
-At the minimum you need a build rule composed of a source branch (or tag) and
-destination Docker tag to set up an automated build. You can also change where
-the build looks for the Dockerfile, set a path to the files the build use
-(the build context), set up multiple static tags or branches to build from, and
-use regular expressions (regexes) to dynamically select source code to build and
-create dynamic tags.
+At the minimum you need a build rule composed of a source branch, or tag, and a
+destination Docker tag to set up an automated build. You can also:
+
+- Change where the build looks for the Dockerfile
+- Set a path to the files the build should use (the build context)
+- Set up multiple static tags or branches to build from
+- Use regular expressions (regexes) to dynamically select source code to build and
+create dynamic tags
All of these options are available from the **Build configuration** screen for
-each repository. Select **Repositories** from the left navigation, and select the name of the repository you want to edit. Select the **Builds** tab, and click **Configure Automated builds**.
+each repository. Select **Repositories** from the left navigation, and select the name of the repository you want to edit. Select the **Builds** tab, and then select **Configure Automated builds**.
### Tag and branch builds
You can configure your automated builds so that pushes to specific branches or tags triggers a build.
-1. In the **Build Rules** section, click the plus sign to add more sources to build.
+1. In the **Build Rules** section, select the **plus** icon to add more sources to build.
-2. Select the **Source type** to build: either a tag or a branch.
+2. Select the **Source type** to build either a tag or a branch.
> Note
>
@@ -291,7 +191,7 @@ Depending on how you arrange the files in your source code repository, the
files required to build your images may not be at the repository root. If that's
the case, you can specify a path where the build looks for the files.
-The _build context_ is the path to the files needed for the build, relative to
+The build context is the path to the files needed for the build, relative to
the root of the repository. Enter the path to these files in the **Build context** field. Enter `/` to set the build context as the root of the source code repository.
> **Note**
@@ -303,17 +203,16 @@ the root of the repository. Enter the path to these files in the **Build context
You can specify the **Dockerfile location** as a path relative to the build
context. If the Dockerfile is at the root of the build context path, leave the
-Dockerfile path set to `/`. (If the build context field is blank, set the path
-to the Dockerfile from the root of the source repository.)
+Dockerfile path set to `/`. If the build context field is blank, set the path
+to the Dockerfile from the root of the source repository.
-### Regexes and automated builds
+### Regexes and Automated builds
You can specify a regular expression (regex) so that only matching branches or
tags are built. You can also use the results of the regex to create the Docker
tag that's applied to the built image.
-You can use up to nine regular expression capture groups
-(expressions enclosed in parentheses) to select a source to build, and reference
+You can use up to nine regular expression capture groups, or expressions enclosed in parentheses, to select a source to build, and reference
these in the **Docker Tag** field using `{\1}` through `{\9}`.
@@ -33,7 +68,7 @@ Docker provides a [Docker Hub CLI](https://github.com/docker/hub-tool#readme){:
-
+
Sign up and create a new Docker ID
-
- 
-
- 
+ 
+ 
+ 
+ 
+ 
+ 
