mirror of https://github.com/docker/docs.git
Engdocs 1268 (#16945)
* change to image managment * edits * move content about * edit index.md page * edit index.md * edit manage-builds.md * edit remaining pages * fix broken links * tidy * tidy * ENGDOCS-1268
This commit is contained in:
Allie Sadler
GitHub
parent
c35260743f
commit
787239a585
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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}`.
|
||||
|
||||
<!-- Capture groups Not a priority
|
||||
|
|
@ -331,56 +230,20 @@ Docker build system, add the [environment variable](index.md#environment-variabl
|
|||
`DOCKER_BUILDKIT=0`. Refer to the [BuildKit](../../build/buildkit/index.md)
|
||||
page for more information on BuildKit.
|
||||
|
||||
## Build repositories with linked private submodules
|
||||
|
||||
Docker Hub sets up a deploy key in your source code repository that allows it
|
||||
to clone the repository and build it; however this key only works for a single,
|
||||
specific code repository. If your source code repository uses private Git
|
||||
submodules (or requires that you clone other private repositories to build),
|
||||
Docker Hub cannot access these additional repos, your build cannot complete,
|
||||
and an error is logged in your build timeline.
|
||||
|
||||
To work around this, you can set up your automated build using the `SSH_PRIVATE`
|
||||
environment variable to override the deployment key and grant Docker Hub's build
|
||||
system access to the repositories.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> If you are using autobuild for teams, use [the process below](index.md#service-users-for-team-autobuilds)
|
||||
> instead, and configure a service user for your source code provider. You can
|
||||
> also do this for an individual account to limit Docker Hub's access to your
|
||||
> source repositories.
|
||||
|
||||
1. Generate a SSH keypair that you use for builds only, and add the public key to your source code provider account.
|
||||
|
||||
This step is optional, but allows you to revoke the build-only keypair without removing other access.
|
||||
|
||||
2. Copy the private half of the keypair to your clipboard.
|
||||
3. In Docker Hub, navigate to the build page for the repository that has linked private submodules. (If necessary, follow the steps [here](index.md#configure-automated-build-settings) to configure the automated build.)
|
||||
4. At the bottom of the screen, click the plus sign ( **+** ) next to **Build Environment variables**.
|
||||
5. Enter `SSH_PRIVATE` as the name for the new environment variable.
|
||||
6. Paste the private half of the keypair into the **Value** field.
|
||||
7. Click **Save**, or **Save and Build** to validate that the build now completes.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You must configure your private git submodules using git clone over SSH
|
||||
> (`git@submodule.tld:some-submodule.git`) rather than HTTPS.
|
||||
|
||||
## Autobuild for Teams
|
||||
|
||||
When you create an automated build repository in your own account namespace, you
|
||||
When you create an automated build repository in your own user account, you
|
||||
can start, cancel, and retry builds, and edit and delete your own repositories.
|
||||
|
||||
These same actions are also available for team repositories from Docker Hub if
|
||||
you are a member of the Organization's `Owners` team. If you are a member of a
|
||||
you are a member of an organization's `Owners` team. If you are a member of a
|
||||
team with `write` permissions you can start, cancel, and retry builds in your
|
||||
team's repositories, but you cannot edit the team repository settings or delete
|
||||
the team repositories. If your user account has `read` permission, or if you're
|
||||
a member of a team with `read` permission, you can view the build configuration
|
||||
including any testing settings.
|
||||
|
||||
| Action/Permission | read | write | admin | owner |
|
||||
| Action/Permission | Read | Write | Admin | Owner |
|
||||
| --------------------- | ---- | ----- | ----- | ----- |
|
||||
| view build details | x | x | x | x |
|
||||
| start, cancel, retry | | x | x | x |
|
||||
|
|
@ -389,14 +252,16 @@ including any testing settings.
|
|||
|
||||
### Service users for team autobuilds
|
||||
|
||||
> **Note**: Only members of the `Owners` team can set up automated builds for teams.
|
||||
> **Note**
|
||||
>
|
||||
> Only members of the `Owners` team can set up Automated builds for teams.
|
||||
|
||||
When you set up automated builds for teams, you grant Docker Hub access to
|
||||
When you set up Automated builds for teams, you grant Docker Hub access to
|
||||
your source code repositories using OAuth tied to a specific user account. This
|
||||
means that Docker Hub has access to everything that the linked source provider
|
||||
account can access.
|
||||
|
||||
For organizations and teams, it's recommended you create a dedicated service account (or "machine user") to grant access to the source provider. This ensures that no
|
||||
For organizations and teams, it's recommended you create a dedicated service account to grant access to the source provider. This ensures that no
|
||||
builds break as individual users' access permissions change, and that an
|
||||
individual user's personal projects aren't exposed to an entire organization.
|
||||
|
||||
|
|
@ -407,7 +272,7 @@ set of repositories required for a specific build.
|
|||
|
||||
If you are building repositories with linked private submodules (private
|
||||
dependencies), you also need to add an override `SSH_PRIVATE` environment
|
||||
variable to automated builds associated with the account.
|
||||
variable to automated builds associated with the account. For more information, see [Troubleshoot](troubleshoot.md#build-repositories-with-linked-private-submodules)
|
||||
|
||||
1. Create a service user account on your source provider, and generate SSH keys for it.
|
||||
2. Create a "build" team in your organization.
|
||||
|
|
@ -419,27 +284,17 @@ variable to automated builds associated with the account.
|
|||
|
||||
4. Add the service user to the "build" team on the source provider.
|
||||
|
||||
5. Log in to Docker Hub as a member of the `Owners` team, switch to the organization, and follow the instructions to [link to source code repository](link-source.md) using the service account.
|
||||
5. Sign in to Docker Hub as a member of the `Owners` team, switch to the organization, and follow the instructions to [link to source code repository](link-source.md) using the service account.
|
||||
|
||||
> **Note**: You may need to log out of your individual account on the source code provider to create the link to the service account.
|
||||
> **Note**
|
||||
>
|
||||
> You may need to log out of your individual account on the source code provider to create the link to the service account.
|
||||
|
||||
6. Optionally, use the SSH keys you generated to set up any builds with private submodules, using the service account and [the instructions above](index.md#build-repositories-with-linked-private-submodules).
|
||||
6. Optional: Use the SSH keys you generated to set up any builds with private submodules, using the service account and [the instructions above](troubleshoot.md#build-repositories-with-linked-private-submodules).
|
||||
|
||||
## What's Next?
|
||||
|
||||
### Customize your build process
|
||||
|
||||
Additional advanced options are available for customizing your automated builds,
|
||||
including utility environment variables, hooks, and build phase overrides. To
|
||||
learn more see [Advanced options for Autobuild and Autotest](advanced.md).
|
||||
|
||||
### Add automated tests
|
||||
|
||||
To test your code before the image is pushed, you can use
|
||||
Docker Hub's [Autotest](automated-testing.md) feature which
|
||||
integrates seamlessly with autobuild and autoredeploy.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> While the Autotest feature builds an image for testing purposes, it
|
||||
> doesn't push the resulting image to Docker Hub.
|
||||
- [Customize your build process](advanced.md) with environment variables, hooks, and more
|
||||
- [Add automated tests](automated-testing.md)
|
||||
- [Manage your builds](manage-builds.md)
|
||||
- [Troubleshoot](troubleshoot.md)
|
||||
|
|
@ -1,91 +1,53 @@
|
|||
---
|
||||
description: Link to GitHub and BitBucket
|
||||
keywords: Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, trusted, builds, trusted builds, automated builds, GitHub
|
||||
title: Configure automated builds from GitHub and BitBucket
|
||||
title: Configure Automated builds from GitHub and BitBucket
|
||||
redirect_from:
|
||||
- /docker-hub/github/
|
||||
- /docker-hub/bitbucket/
|
||||
- /docker-cloud/builds/link-source/
|
||||
---
|
||||
|
||||
{% 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).
|
||||
|
||||
To automate building and testing of your images, you link to your hosted source
|
||||
code service to Docker Hub so that it can access your source code
|
||||
repositories. You can configure this link for user accounts or
|
||||
organizations.
|
||||
|
||||
|
||||
> **Note**: If you are linking a source code provider to create autobuilds for a team, follow the instructions to [create a service account](index.md#service-users-for-team-autobuilds) for the team before linking the account as described below.
|
||||
If you are linking a source code provider to create autobuilds for a team, follow the instructions to [create a service account](index.md#service-users-for-team-autobuilds) for the team before linking the account as described below.
|
||||
|
||||
## Link to a GitHub user account
|
||||
|
||||
1. Log in to Docker Hub using your Docker ID.
|
||||
1. Sign in to Docker Hub.
|
||||
|
||||
2. Click **Account Settings** in the top-right dropdown navigation, then open **Linked Accounts**.
|
||||
2. Select **Account Settings** in the top-right dropdown navigation, then select the **Linked Accounts** tab.
|
||||
|
||||
3. Click **Connect** for the source provider you want to link.
|
||||
3. Select **Link provider** for the source provider you want to link.
|
||||
|
||||
|
||||
|
||||
> **Note**: If you want to unlink your current GitHub account and relink to a new GitHub account, make sure to completely logout of [GitHub] (https://github.com/){: target="_blank" rel="noopener"
|
||||
class="_"} before linking via Docker Hub.
|
||||
If you want to unlink your current GitHub account and relink to a new GitHub account, make sure to completely logout of [GitHub](https://github.com/){: target="_blank" rel="noopener"
|
||||
class="_"} before linking via Docker Hub.
|
||||
|
||||
|
||||
4. Review the settings for the **Docker Hub Builder** OAuth application.
|
||||
|
||||
|
||||
{:width="750px"}
|
||||
|
||||
>**Note**: If you are the owner of any GitHub organizations, you might see
|
||||
>**Note**
|
||||
>
|
||||
> If you are the owner of any GitHub organizations, you might see
|
||||
options to grant Docker Hub access to them from this screen. You can also
|
||||
individually edit an organization's third-party access settings to grant or
|
||||
revoke Docker Hub's access. See
|
||||
[Grant access to a GitHub organization](link-source.md#grant-access-to-a-github-organization)
|
||||
to learn more.
|
||||
|
||||
5. Click **Authorize docker** to save the link.
|
||||
5. Select **Authorize docker** to save the link.
|
||||
|
||||
## Link to a Bitbucket user account
|
||||
|
||||
1. Log in to Docker Hub using your Docker ID.
|
||||
|
||||
2. Click **Account Settings** in the top-right dropdown navigation, then open
|
||||
the **Linked Accounts** section.
|
||||
|
||||
3. Click **Connect** for the source provider you want to link.
|
||||
|
||||
|
||||
|
||||
4. If necessary, log in to Bitbucket.
|
||||
|
||||
5. On the page that appears, click **Grant access**.
|
||||
|
||||
### Unlink a GitHub user account
|
||||
|
||||
To revoke Docker Hub's access to your GitHub account, you must unlink it both
|
||||
from Docker Hub, *and* from your GitHub account.
|
||||
|
||||
1. Click **Account Settings** in the top-right dropdown navigation, then open
|
||||
the **Linked Accounts** section.
|
||||
|
||||
2. Click the plug icon next to the source provider you want to remove.
|
||||
|
||||
3. Go to your GitHub account's **Settings** page.
|
||||
|
||||
4. Click **Applications** in the left navigation bar.
|
||||
|
||||
5. Click the `...` menu to the right of the Docker Hub Builder application and select **Revoke**.
|
||||
|
||||
> **Note**: Each repository that is configured as an automated build source
|
||||
contains a webhook that notifies Docker Hub of changes in the repository.
|
||||
This webhook is not automatically removed when you revoke access to a source
|
||||
code provider.
|
||||
|
||||
## Grant access to a GitHub organization
|
||||
### Grant access to a GitHub organization
|
||||
|
||||
If you are the owner of a GitHub organization, you can grant or revoke Docker
|
||||
Hub's access to the organization's repositories. Depending on the GitHub
|
||||
|
|
@ -94,11 +56,9 @@ organization's settings, you may need to be an organization owner.
|
|||
If the organization has not had specific access granted or revoked before, you
|
||||
can often grant access at the same time as you link your user account. In this
|
||||
case, a **Grant access** button appears next to the organization name in the
|
||||
link accounts screen, as shown below. If this button does not appear, you must
|
||||
link accounts screen, as shown below. If this button does not appear, you must
|
||||
manually grant the application's access.
|
||||
|
||||
|
||||
|
||||
To manually grant Docker Hub access to a GitHub organization:
|
||||
|
||||
1. Link your user account using the instructions above.
|
||||
|
|
@ -106,19 +66,16 @@ To manually grant Docker Hub access to a GitHub organization:
|
|||
2. From your GitHub Account settings, locate the **Organization settings**
|
||||
section at the lower left.
|
||||
|
||||
3. Click the organization you want to give Docker Hub access to.
|
||||
3. Select the organization you want to give Docker Hub access to.
|
||||
|
||||
4. From the Organization Profile menu, click **Third-party access**.
|
||||
4. Select **Third-party access**.
|
||||
|
||||
The page displays a list of third party applications and their access
|
||||
status.
|
||||
|
||||
5. Click the pencil icon next to Docker Hub Builder.
|
||||
|
||||
6. Click **Grant access** next to the organization.
|
||||
|
||||
|
||||
5. Select the pencil icon next to **Docker Hub Builder**.
|
||||
|
||||
6. Select **Grant access** next to the organization.
|
||||
|
||||
### Revoke access to a GitHub organization
|
||||
|
||||
|
|
@ -133,30 +90,65 @@ To revoke Docker Hub's access to an organization's GitHub repositories:
|
|||
|
||||
4. Click the pencil icon next to Docker Hub Builder.
|
||||
|
||||
5. On the next page, click **Deny access**.
|
||||
5. On the next page, select **Deny access**.
|
||||
|
||||
### Unlink a GitHub user account
|
||||
|
||||
To revoke Docker Hub's access to your GitHub account, you must unlink it both
|
||||
from Docker Hub, and from your GitHub account.
|
||||
|
||||
1. Select **Account Settings** in the top-right dropdown navigation, then open
|
||||
the **Linked Accounts** section.
|
||||
|
||||
2. Select the plug icon next to the source provider you want to remove.
|
||||
|
||||
3. Go to your GitHub account's **Settings** page.
|
||||
|
||||
4. Select **Applications** in the left navigation bar.
|
||||
|
||||
5. Select the `...` menu to the right of the Docker Hub Builder application and select **Revoke**.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Each repository that is configured as an automated build source
|
||||
contains a webhook that notifies Docker Hub of changes in the repository.
|
||||
This webhook is not automatically removed when you revoke access to a source
|
||||
code provider.
|
||||
|
||||
## Link to a Bitbucket user account
|
||||
|
||||
1. Sign in to Docker Hub using your Docker ID.
|
||||
|
||||
2. Select **Account Settings** in the top-right dropdown navigation, then select the **Linked Accounts** tab.
|
||||
|
||||
3. Select **Link provider** for the source provider you want to link.
|
||||
|
||||
4. If necessary, sign in to Bitbucket.
|
||||
|
||||
5. On the page that appears, select **Grant access**.
|
||||
|
||||
|
||||
### Unlink a Bitbucket user account
|
||||
|
||||
To permanently revoke Docker Hub's access to your Bitbucket account, you must
|
||||
unlink it both from Docker Hub, *and* from your Bitbucket account.
|
||||
unlink it both from Docker Hub, and from your Bitbucket account.
|
||||
|
||||
1. Log in to Docker Hub using your Docker ID.
|
||||
1. Sign in to Docker Hub.
|
||||
|
||||
2. Click **Account Settings** in the top-right dropdown navigation, then open
|
||||
2. Select **Account Settings** in the top-right dropdown navigation, then open
|
||||
the **Linked Accounts** section.
|
||||
|
||||
3. Click the plug icon next to the source provider you want to remove.
|
||||
3. Select the **Plug** icon next to the source provider you want to remove.
|
||||
|
||||
4. Go to your Bitbucket account and click the user menu icon in the top-right corner.
|
||||
4. Go to your Bitbucket account and navigate to **Bitbucket settings**.
|
||||
|
||||
5. Click **Bitbucket settings**.
|
||||
5. On the page that appears, select **OAuth**.
|
||||
|
||||
6. On the page that appears, click **OAuth**.
|
||||
6. Select **Revoke** next to the Docker Hub line.
|
||||
|
||||
7. Click **Revoke** next to the Docker Hub line.
|
||||
|
||||
> **Note**: Each repository that is configured as an automated build source
|
||||
> **Note**
|
||||
>
|
||||
> Each repository that is configured as an automated build source
|
||||
contains a webhook that notifies Docker Hub of changes in the repository. This
|
||||
webhook is not automatically removed when you revoke access to a source code
|
||||
provider.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,59 @@
|
|||
---
|
||||
title: Manage autobuilds
|
||||
description: How to manage autobuilds in Docker Hub
|
||||
keywords: autobuilds, automated, docker hub, registry
|
||||
---
|
||||
> **Note**
|
||||
>
|
||||
> Automated builds require a
|
||||
> [Docker Pro, Team, or Business subscription](../../subscription/index.md).
|
||||
|
||||
## 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 select
|
||||
**Cancel** on the **Build report** page, or from the **Timeline** tab's logs
|
||||
display for the build.
|
||||
|
||||
|
||||
|
||||
## 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 account 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.
|
||||
|
||||
|
||||
|
||||
## 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. Disabling 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. Select **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. Select the **Autobuild** toggle next to the configuration line. When disabled the toggle is gray.
|
||||
|
||||
5. Select **Save**.
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
title: Troubleshoot your builds
|
||||
description: How to troubleshoot Automated builds
|
||||
keywords: docker hub, troubleshoot, automated builds, autobuilds
|
||||
---
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Automated builds require a
|
||||
> [Docker Pro, Team, or Business subscription](../../subscription/index.md).
|
||||
|
||||
## 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.
|
||||
|
||||
|
||||
## Build repositories with linked private submodules
|
||||
|
||||
Docker Hub sets up a deploy key in your source code repository that allows it
|
||||
to clone the repository and build it. This key only works for a single,
|
||||
specific code repository. If your source code repository uses private Git
|
||||
submodules, or requires that you clone other private repositories to build,
|
||||
Docker Hub cannot access these additional repositories, your build cannot complete,
|
||||
and an error is logged in your build timeline.
|
||||
|
||||
To work around this, you can set up your automated build using the `SSH_PRIVATE`
|
||||
environment variable to override the deployment key and grant Docker Hub's build
|
||||
system access to the repositories.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> If you are using autobuild for teams, use the process below
|
||||
> instead, and configure a service user for your source code provider. You can
|
||||
> also do this for an individual account to limit Docker Hub's access to your
|
||||
> source repositories.
|
||||
|
||||
1. Generate a SSH keypair that you use for builds only, and add the public key to your source code provider account.
|
||||
|
||||
This step is optional, but allows you to revoke the build-only keypair without removing other access.
|
||||
|
||||
2. Copy the private half of the keypair to your clipboard.
|
||||
3. In Docker Hub, navigate to the build page for the repository that has linked private submodules. (If necessary, follow the steps [here](index.md#configure-automated-builds) to configure the automated build.)
|
||||
4. At the bottom of the screen, select the **plus** icon next to **Build Environment variables**.
|
||||
5. Enter `SSH_PRIVATE` as the name for the new environment variable.
|
||||
6. Paste the private half of the keypair into the **Value** field.
|
||||
7. Select **Save**, or **Save and Build** to validate that the build now completes.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> You must configure your private git submodules using git clone over SSH
|
||||
> (`git@submodule.tld:some-submodule.git`) rather than HTTPS.
|
||||
|
|
@ -4,7 +4,10 @@ keywords: dashboard, images, image management, inactive
|
|||
title: Advanced Image Management dashboard
|
||||
---
|
||||
|
||||
{% include upgrade-cta.html %}
|
||||
> **Note**
|
||||
>
|
||||
> Image management requires a
|
||||
> [Docker Pro, Team, or Business subscription](../subscription/index.md).
|
||||
|
||||
Advanced Image Management allows you to manage Docker images across all repositories and streamline storage in Docker Hub.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Take a look at the [Docker Public Roadmap](https://github.com/docker/roadmap/pro
|
|||
|
||||
### New
|
||||
|
||||
- The new [autobuild feature](../docker-hub/builds/index.md#check-your-active-builds) lets you view your in-progress logs every 30 seconds instead of when the build is complete.
|
||||
- The new [autobuild feature](../docker-hub/builds/manage-builds.md#check-your-active-builds) lets you view your in-progress logs every 30 seconds instead of when the build is complete.
|
||||
|
||||
## 2022-09-21
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ You should use the Registry if you want to:
|
|||
Users looking for a zero maintenance, ready-to-go solution are encouraged to
|
||||
head-over to the [Docker Hub](https://hub.docker.com), which provides a
|
||||
free-to-use, hosted Registry, plus additional features (organization accounts,
|
||||
automated builds, and more).
|
||||
Automated builds, and more).
|
||||
|
||||
## Requirements
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue