diff --git a/_data/toc.yaml b/_data/toc.yaml index 24af845d5b..f1145325bb 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -1797,12 +1797,18 @@ manuals: title: Docker Official images - sectiontitle: Automated builds section: + - path: /docker-hub/builds/how-builds-work/ + title: How Automated builds work - path: /docker-hub/builds/ - title: Set up automated builds + title: Set up Automated builds + - path: /docker-hub/builds/manage-builds/ + title: Manage your builds + - path: /docker-hub/builds/troubleshoot/ + title: Troubleshoot your builds - path: /docker-hub/builds/automated-testing/ - title: Testing in automated builds + title: Testing in Automated builds - path: /docker-hub/builds/advanced/ - title: Advanced automated builds + title: Advanced options for builds - path: /docker-hub/builds/link-source/ title: Link to GitHub and BitBucket - path: /docker-hub/webhooks/ 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. + +![An automated build dashboard](images/index-dashboard.png){: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. - -![An automated build dashboard](images/index-dashboard.png) - -## 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. - -![Active builds](images/index-active.png) - -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. - -![Build report](/docker-hub/images/index-report.png) - -## 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. - -![List of builds showing the cancel icon](images/build-cancelicon.png) - -## 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. - -![Timeline view showing the retry build button](images/retry-build.png) - -> **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}`.