mirror of https://github.com/docker/docs.git
Fix missing build changes & toc fixes
This commit is contained in:
Jeffrey Morgan
parent
893c82a11f
commit
1f5d8fdb3e
|
|
@ -3641,26 +3641,24 @@ manuals:
|
|||
title: Slack Integration
|
||||
- path: /docker-hub/upgrade/
|
||||
title: Upgrading your plan
|
||||
- sectiontitle: Builds
|
||||
- sectiontitle: Automated Builds
|
||||
section:
|
||||
- path: /docker-hub/builds/
|
||||
title: Get Started with Builds
|
||||
title: Set up Automated builds
|
||||
- path: /docker-hub/builds/automated-testing/
|
||||
title: Testing in Builds
|
||||
title: Testing in Automated Builds
|
||||
- path: /docker-hub/builds/advanced/
|
||||
title: Advanced Builds
|
||||
- path: /docker-hub/builds/github/
|
||||
title: Connecting GitHub
|
||||
- path: /docker-hub/builds/bitbucket/
|
||||
title: Connecting BitBucket
|
||||
- sectiontitle: Publisher Images & Plugins
|
||||
title: Advanced Automated Builds
|
||||
- path: /docker-hub/builds/link-source/
|
||||
title: Link to GitHub and BitBucket
|
||||
- sectiontitle: Publisher & Certified Content
|
||||
section:
|
||||
- path: /docker-hub/customer_faq/
|
||||
title: Subscriptions
|
||||
- path: /docker-hub/publish/publisher_faq/
|
||||
title: Publishers
|
||||
- path: /docker-hub/publish/
|
||||
title: Publish Images & Plugins
|
||||
title: Overview
|
||||
- path: /docker-hub/publish/customer_faq/
|
||||
title: User FAQs
|
||||
- path: /docker-hub/publish/publisher_faq/
|
||||
title: Publisher FAQs
|
||||
- path: /docker-hub/publish/certify-images/
|
||||
title: Certify Images & Plugins
|
||||
- path: /docker-hub/publish/certify-plugins-logging/
|
||||
|
|
|
|||
|
|
@ -1,418 +0,0 @@
|
|||
---
|
||||
description: Set up Automated builds
|
||||
keywords: automated, build, images
|
||||
redirect_from:
|
||||
- /docker-cloud/feature-reference/automated-build/
|
||||
- /docker-cloud/builds/automated-build/
|
||||
title: Set up Automated 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 or to an
|
||||
external registry.
|
||||
|
||||
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 does not push the built
|
||||
image. Automated tests do not push images to the registry on their own. [Learn more about automated image testing here.](automated-testing.md)
|
||||
|
||||
> **Note**: You can still use `docker push` to push pre-built images to
|
||||
repositories with Automated Builds configured.
|
||||
|
||||
|
||||
|
||||
## Configure automated build settings
|
||||
|
||||
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.
|
||||
|
||||
Before you set up automated builds you need to [create a repository](repos.md) to build, and [link to your source code provider](link-source.md).
|
||||
|
||||
1. From the **Repositories** section, click into a repository to view its details.
|
||||
|
||||
2. Click the **Builds** tab.
|
||||
|
||||
3. If you are setting up automated builds for the first time, select
|
||||
the code repository service where the image's source code is stored.
|
||||
|
||||
Otherwise, if you are editing the build settings for an existing automated
|
||||
build, click **Configure automated builds**.
|
||||
|
||||
4. Select the **source repository** to build the Docker images from.
|
||||
|
||||
You might need to specify an organization or user (the _namespace_) from the
|
||||
source code provider. Once you select a namespace, its source code
|
||||
repositories appear in the **Select repository** dropdown list.
|
||||
|
||||
5. Optionally, enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository).
|
||||
|
||||
6. Review the default **Build Rules**, and optionally click the
|
||||
**plus sign** to add and configure more build rules.
|
||||
|
||||
_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`.
|
||||
|
||||
7. 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 is not pushed to the repository.
|
||||
|
||||
8. For each branch or tag, enable or disable the **Build Caching** toggle.
|
||||
|
||||
[Build caching](/engine/userguide/eng-image/dockerfile_best-practices/#/build-cache) can save time if you are building a large image frequently or have
|
||||
many dependencies. You might want to leave build caching disabled to
|
||||
make sure all of your dependencies are resolved at build time, or if
|
||||
you have a large layer that is quicker to build locally.
|
||||
|
||||
9. Click **Save** to save the settings, or click **Save and build** to save and
|
||||
run an initial test.
|
||||
|
||||
A webhook is automatically added to your source code repository to notify
|
||||
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 autobuilds, 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
|
||||
`latest`. You
|
||||
|
||||
In the **Build Rules** section, enter one or more sources to build.
|
||||
|
||||
For each source:
|
||||
|
||||
* Select the **Source type** to build either a **tag** or a
|
||||
**branch**. This tells the build system what to look for in the source code
|
||||
repository.
|
||||
|
||||
* 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
|
||||
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](automated-build.md#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](automated-build.md#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)
|
||||
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
|
||||
then entering a variable name and the value.
|
||||
|
||||
When you set variable values from the Docker Hub UI, they can be used by the
|
||||
commands you set in `hooks` files, but they are stored so that only users who
|
||||
have `admin` access to the Docker Hub repository can see their values. This
|
||||
means you can use them to safely store access tokens or other information that
|
||||
should remain secret.
|
||||
|
||||
> **Note**: The variables set on the build configuration screen are used during
|
||||
the build processes _only_ and should not be 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 click a build job to view its build report. The
|
||||
build report shows information about the build job including the source
|
||||
repository and branch (or tag), the build duration, creation time and location,
|
||||
and the user namespace the build occurred in.
|
||||
|
||||
|
||||
|
||||
## Cancel or retry a build
|
||||
|
||||
While a build is queued 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** button from the build report page, or from the Timeline tab's logs
|
||||
display for the build.
|
||||
|
||||
|
||||
|
||||
If a build fails, a **Retry** icon appears next to the build report line on the
|
||||
General and Builds tabs, and 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.
|
||||
|
||||
|
||||
## Disable an automated build
|
||||
|
||||
Automated builds are enabled per branch or tag, and can be disabled and
|
||||
re-enabled easily. 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 does not disable [autotests](automated-testing.md).
|
||||
|
||||
To disable an automated build:
|
||||
|
||||
1. From the **Repositories** page, click into a repository, and click 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.
|
||||
|
||||
The toggle turns gray when disabled.
|
||||
|
||||
5. Click **Save** to save your changes.
|
||||
|
||||
## 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.
|
||||
|
||||
All of these options are available from the **Build configuration** screen for
|
||||
each repository. Click **Repositories** from the left navigation, click the name
|
||||
of the repository you want to edit, click the **Builds** tab, and click
|
||||
**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.
|
||||
|
||||
2. Select the **Source type** to build: either a **tag** or a **branch**.
|
||||
|
||||
This tells the build system what type of source to look for in the code
|
||||
repository.
|
||||
|
||||
3. Enter the name of the **Source** branch or tag you want to build.
|
||||
|
||||
You can enter a name, or use a regex to match which source branch or tag
|
||||
names to build. To learn more, see
|
||||
[regexes](automated-build.md#regexes-and-automated-builds).
|
||||
|
||||
4. 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](automated-build.md#regexes-and-automated-builds).
|
||||
|
||||
5. Repeat steps 2 through 4 for each new build rule you set up.
|
||||
|
||||
### Set the build context and Dockerfile location
|
||||
|
||||
Depending on how the files are arranged 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 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**: If you delete the default path `/` from the **Build context** field and leave it blank, the build system uses the path to the Dockerfile as the build context. However, to avoid confusion we recommend that you specify the complete path.
|
||||
|
||||
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.)
|
||||
|
||||
### 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 is applied to the built image.
|
||||
|
||||
You can use the variable `{sourceref}` to use the branch or tag name that
|
||||
matched the regex in the Docker tag applied to the resulting built image. (The
|
||||
variable includes the whole source name, not just the portion that matched the
|
||||
regex.) You can also use up to nine regular expression capture groups
|
||||
(expressions enclosed in parentheses) to select a source to build, and reference
|
||||
these in the Docker Tag field using `{\1}` through `{\9}`.
|
||||
|
||||
**Regex example: build from version number branch and tag with version number**
|
||||
|
||||
You might want to automatically build any branches that end with a number
|
||||
formatted like a version number, and tag their resulting Docker images using a
|
||||
name that incorporates that branch name.
|
||||
|
||||
To do this, specify a `branch` build with the regex `/[0-9.]+$/` in the
|
||||
**Source** field, and use the formula `version-{sourceref}` in the **Docker
|
||||
tag** field.
|
||||
|
||||
<!-- Capture groups Not a priority
|
||||
#### Regex example: build from version number branch and tag with version number
|
||||
|
||||
You could also use capture groups to build and label images that come from various sources. For example, you might have
|
||||
|
||||
`/(alice|bob)-v([0-9.]+)/` -->
|
||||
|
||||
### Create multiple Docker tags from a single build
|
||||
|
||||
By default, each build rule builds a source branch or tag into a Docker image,
|
||||
and then tags that image with a single tag. However, you can also create several
|
||||
tagged Docker images from a single build rule.
|
||||
|
||||
To create multiple tags from a single build rule, enter a comma-separated list
|
||||
of tags in the **Docker tag** field in the build rule. If an image with that tag
|
||||
already exists, Docker Hub overwrites the image when the build completes
|
||||
successfully. If you have automated tests configured, the build must pass these
|
||||
tests as well before the image is overwritten. You can use both regex references
|
||||
and plain text values in this field simultaneously.
|
||||
|
||||
For example if you want to update the image tagged with `latest` at the same
|
||||
time as you a tag an image for a specific version, you could enter
|
||||
`{sourceref},latest` in the Docker Tag field.
|
||||
|
||||
If you need to update a tag _in another repository_, use [a post_build hook](advanced.md#push-to-multiple-repos) to push to a second repository.
|
||||
|
||||
## 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](automated-build.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](automated-build.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 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
|
||||
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 |
|
||||
| --------------------- | ---- | ----- | ----- | ----- |
|
||||
| view build details | x | x | x | x |
|
||||
| start, cancel, retry | | x | x | x |
|
||||
| edit build settings | | | x | x |
|
||||
| delete build | | | | x |
|
||||
|
||||
### Service users for team autobuilds
|
||||
|
||||
> **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
|
||||
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, we recommend creating a dedicated service account
|
||||
(or "machine user") 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 are not exposed to an entire organization.
|
||||
|
||||
This service account should have access to any repositories to be built,
|
||||
and must have administrative access to the source code repositories so it can
|
||||
manage deploy keys. If needed, you can limit this account to only a specific
|
||||
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.
|
||||
|
||||
1. Create a service user account on your source provider, and generate SSH keys for it.
|
||||
2. Create a "build" team in your organization.
|
||||
3. Ensure that the new "build" team has access to each repository and submodule you need to build.
|
||||
|
||||
Go to the repository's **Settings** page. On Github, add the new "build" team to the list of **Collaborators and Teams**. On Bitbucket, add the "build" team to the list of approved users on the **Access management** screen.
|
||||
|
||||
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.
|
||||
|
||||
> **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](automated-build.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).
|
||||
|
||||
### Set up builder nodes
|
||||
|
||||
If you are building on your own infrastructure, you can run the build process on
|
||||
specific nodes by adding the `builder` label to them. If no builder nodes are
|
||||
specified, the build containers are deployed using an "emptiest node" strategy.
|
||||
|
||||
You can also limit the number of concurrent builds (including `autotest` builds)
|
||||
on a specific node by using a `builder=n` tag, where the `n` is the number of
|
||||
builds to allow. For example a node tagged with `builder=5` only allows up to
|
||||
five concurrent builds or autotest-builds at the same time.
|
||||
|
||||
### Autoredeploy services on successful build
|
||||
|
||||
You can configure your services to automatically redeploy once the build
|
||||
succeeds. [Learn more about autoredeploy](../apps/auto-redeploy.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
|
||||
does not push the resulting image to Docker Hub or the external registry.
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
---
|
||||
description: Docker Hub Automated Builds using Bitbucket
|
||||
keywords: Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, documentation, trusted, builds, trusted builds, automated builds, bitbucket
|
||||
title: Configure automated builds with Bitbucket
|
||||
redirect_from:
|
||||
- /docker-hub/bitbucket/
|
||||
---
|
||||
|
||||
If you've previously linked Docker Hub to your Bitbucket account, skip to
|
||||
[Creating an Automated Build](bitbucket.md#creating-an-automated-build).
|
||||
|
||||
## Link to your Bitbucket account
|
||||
|
||||
To set up an Automated Build of a repository on Bitbucket, you need to
|
||||
link your [Docker Hub](https://hub.docker.com/account/authorized-services/)
|
||||
account to a Bitbucket account. This allows the registry to see your
|
||||
Bitbucket repositories.
|
||||
|
||||
To add, remove, or view your linked account, go to the **Linked Accounts &
|
||||
Services** section of your Hub profile **Settings**.
|
||||
|
||||
|
||||
|
||||
Then follow the onscreen instructions to authorize and link your Bitbucket
|
||||
account to Docker Hub. Once it is linked, you can create a Docker Hub
|
||||
repository from which to create the Automatic Build.
|
||||
|
||||
## Create an Automated Build
|
||||
|
||||
You can [create an Automated Build](
|
||||
https://hub.docker.com/add/automated-build/bitbucket/) from any of your public
|
||||
or private Bitbucket repositories with a `Dockerfile`.
|
||||
|
||||
To get started, log in to Docker Hub and click the "Create ▼" menu item
|
||||
at the top right of the screen. Then select [Create Automated
|
||||
Build](https://hub.docker.com/add/automated-build/bitbucket/).
|
||||
|
||||
Select the linked Bitbucket account, and then choose a repository to set up
|
||||
an Automated Build for.
|
||||
|
||||
## The Bitbucket webhook
|
||||
|
||||
When you create an Automated Build in Docker Hub, a webhook is added to your
|
||||
Bitbucket repository automatically.
|
||||
|
||||
You can also manually add a webhook from your repository's **Settings** page.
|
||||
Set the URL to `https://registry.hub.docker.com/hooks/bitbucket`, to be
|
||||
triggered for repository pushes.
|
||||
|
||||
|
||||
|
|
@ -1,185 +0,0 @@
|
|||
---
|
||||
description: Docker Hub Automated Builds with GitHub
|
||||
keywords: Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, documentation, trusted, builds, trusted builds, automated builds, GitHub
|
||||
title: Configure automated builds from GitHub
|
||||
redirect_from:
|
||||
- /docker-hub/github/
|
||||
---
|
||||
|
||||
If you've previously linked Docker Hub to your GitHub account,
|
||||
skip to [Creating an Automated Build](github.md#creating-an-automated-build).
|
||||
|
||||
## Linking Docker Hub to a GitHub account
|
||||
|
||||
> Automated Build Permissions
|
||||
|
||||
> Automated Builds currently require *read* and *write* access since
|
||||
> [Docker Hub](https://hub.docker.com) needs to set up a GitHub webhook.
|
||||
> We have no choice here – this is how GitHub manages permissions.
|
||||
> We do guarantee nothing else is touched in your account.
|
||||
|
||||
To set up an Automated Build of a repository on GitHub, you need to
|
||||
link [Docker Hub](https://hub.docker.com/account/authorized-services/) to your
|
||||
GitHub account. This allows the registry to see your GitHub repositories.
|
||||
|
||||
To add, remove or view your linked account, log in to your Docker Hub account. Select **Settings > Linked Accounts & Services**.
|
||||
|
||||
Linking to Github grants Docker Hub access to all of your repositories. Follow the
|
||||
onscreen instructions to authorize and link your GitHub account to Docker Hub.
|
||||
Once it is linked, you can choose a source repository from which to create the Automatic Build.
|
||||
|
||||
You can review and revoke Docker Hub's access by visiting the
|
||||
[GitHub User's Applications settings](https://github.com/settings/applications).
|
||||
|
||||
> **Note**: If you delete the connection to the GitHub account that is used for one of your
|
||||
> automated build repositories, previously built images are still available.
|
||||
> If you re-link to that GitHub account later, the automated build can be started
|
||||
> using the **Start Build** button on the Hub, or if the webhook on the GitHub repository
|
||||
> still exists, it is triggered by any subsequent commits.
|
||||
|
||||
## Changing the GitHub user link
|
||||
|
||||
If you want to remove, or change the level of linking between your GitHub
|
||||
account and Docker Hub, you need to make the change in two places.
|
||||
|
||||
First, remove the **Linked Account** from your Docker Hub **Settings**. Then go to
|
||||
your GitHub account's Personal settings, and in the **Applications** section,
|
||||
***Revoke access***.
|
||||
|
||||
You can now re-link your account at any time.
|
||||
|
||||
## GitHub organizations
|
||||
|
||||
GitHub organizations and private repositories forked from organizations are
|
||||
made available for autobuilds using the "Docker Hub Registry" application, which
|
||||
needs to be added to the organization - and then applied to all users.
|
||||
|
||||
To verify or request access, go to your GitHub **Settings** page. Select the
|
||||
**Applications** section from the left side bar, then click the **View** button for
|
||||
"Docker Hub Registry".
|
||||
|
||||
|
||||
|
||||
The organization's administrators may need to go to the Organization's **Third
|
||||
party access** screen in **Settings** to grant or deny access to Docker Hub
|
||||
Registry application. This change applies to all organization members.
|
||||
|
||||
|
||||
|
||||
More detailed access controls to specific users and GitHub repositories can be
|
||||
managed using the GitHub **People and Teams** interfaces.
|
||||
|
||||
## Creating an Automated Build
|
||||
|
||||
You can [create an Automated Build](
|
||||
https://hub.docker.com/add/automated-build/github/) from any of your
|
||||
public or private GitHub repositories that have a `Dockerfile`.
|
||||
|
||||
Once you've selected the source repository, you can then configure:
|
||||
|
||||
- The Hub user/org namespace the repository is built to - either your Docker ID name, or the name of any Hub organizations your account is in
|
||||
- The Docker repository name the image is built to
|
||||
- The description of the repository
|
||||
- If the visibility of the Docker repository is "Public" or "Private",
|
||||
you can change the accessibility options after the repository has been created.
|
||||
If you add a Private repository to a Hub user namespace, then you can only add other users
|
||||
as collaborators, and those users can view and pull all images in that
|
||||
repository. To configure more granular access permissions, such as using teams of
|
||||
users or allow different users access to different image tags, then you need
|
||||
to add the Private repository to a Hub organization for which your user has Administrator
|
||||
privileges.
|
||||
- Enable or disable rebuilding the Docker image when a commit is pushed to the
|
||||
GitHub repository
|
||||
|
||||
You can also select one or more:
|
||||
- The git branch/tag
|
||||
- A repository sub-directory to use as the context
|
||||
- The Docker image tag name
|
||||
|
||||
You can modify the description for the repository by clicking the "Description" section
|
||||
of the repository view.
|
||||
The "Full Description" is overwritten by the **README.md** file when the
|
||||
next build is triggered.
|
||||
|
||||
## GitHub private submodules
|
||||
|
||||
If your GitHub repository contains links to private submodules, your build fails.
|
||||
|
||||
Normally, Docker Hub sets up a deploy key in your GitHub repository.
|
||||
Unfortunately, GitHub only allows a repository deploy key to access a single
|
||||
repository.
|
||||
|
||||
To work around this, you can create a dedicated user account in GitHub and
|
||||
attach the automated build's deploy key that account. This dedicated build
|
||||
account can be limited to read-only access to just the repositories required to
|
||||
build.
|
||||
|
||||
<table class="table table-bordered">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Step</th>
|
||||
<th>Screenshot</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>1.</td>
|
||||
<td><img src="/docker-hub/images/gh_org_members.png"></td>
|
||||
<td>First, create the new account in GitHub. It should be given read-only
|
||||
access to the main repository and all submodules that are needed.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>2.</td>
|
||||
<td><img src="/docker-hub/images/gh_team_members.png"></td>
|
||||
<td>This can be accomplished by adding the account to a read-only team in
|
||||
the organization(s) where the main GitHub repository and all submodule
|
||||
repositories are kept.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>3.</td>
|
||||
<td><img src="/docker-hub/images/gh_repo_deploy_key.png"></td>
|
||||
<td>Next, remove the deploy key from the main GitHub repository. This can be done in the GitHub repository's "Deploy keys" Settings section.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>4.</td>
|
||||
<td><img src="/docker-hub/images/deploy_key.png"></td>
|
||||
<td>Your automated build's deploy key is in the "Build Details" menu
|
||||
under "Deploy keys".</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>5.</td>
|
||||
<td><img src="/docker-hub/images/gh_add_ssh_user_key.png"></td>
|
||||
<td>In your dedicated GitHub User account, add the deploy key from your
|
||||
Docker Hub Automated Build.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
## GitHub webhook
|
||||
|
||||
A GitHub webhook allows GitHub to notify Docker Hub when something has
|
||||
been committed to a given Git repository.
|
||||
|
||||
When you create an Automated Build, a webhook should get automatically added to your GitHub
|
||||
repository.
|
||||
|
||||
To add, confirm, or modify the webhook, log in to GitHub, then navigate to
|
||||
the repository. Within the repository, select **Settings > Webhooks**.
|
||||
You must have admin privileges on the repository to view or modify
|
||||
this setting. Click **Add webhook**, and use the following settings:
|
||||
|
||||
|
||||
| Field | Value |
|
||||
| ------|------ |
|
||||
| Payload URL | https://registry.hub.docker.com/hooks/github |
|
||||
| Content type | application/json |
|
||||
| Which events would you like to trigger this webhook? | Just the push event |
|
||||
| Active | checked |
|
||||
|
||||
The image below shows the **Webhooks/Add webhook** form with the above settings reflected:
|
||||
|
||||
|
||||
|
||||
If configured correctly, you'll see this in the **Webhooks** view
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 188 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 254 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 313 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 96 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 116 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
|
|
@ -1,24 +1,421 @@
|
|||
---
|
||||
description: Overview
|
||||
keywords: builds, images, Hub
|
||||
title: Overview
|
||||
notoc: true
|
||||
description: Set up Automated builds
|
||||
keywords: automated, build, images
|
||||
redirect_from:
|
||||
- /docker-cloud/feature-reference/automated-build/
|
||||
- /docker-cloud/builds/automated-build/
|
||||
- /docker-cloud/builds/
|
||||
- /docker-cloud/builds/repos/
|
||||
- /docker-cloud/builds/push-images/
|
||||
title: Set up Automated builds
|
||||
---
|
||||
|
||||
Docker Hub provides a hosted registry service where you can create
|
||||
repositories to store your Docker images. You can choose to push images to the
|
||||
repositories directly, or link to your source code and build them in Docker
|
||||
Hub.
|
||||
## How Automated Builds work
|
||||
|
||||
You can build images manually, or set up automated builds to rebuild your Docker
|
||||
image on each `git push` to the source code.
|
||||
Docker Hub can automatically build images from source code in an external
|
||||
repository and automatically push the built image to your Docker
|
||||
repositories.
|
||||
|
||||
For more information, see:
|
||||
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 or to an
|
||||
external registry.
|
||||
|
||||
* [Automated Builds](automated-build.md)
|
||||
* [Automated Repository tests](automated-testing.md)
|
||||
* [Advanced options for Autobuild and Autotest](advanced.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 does not push the built
|
||||
image. Automated tests do not push images to the registry on their own. [Learn more about automated image testing here.](automated-testing.md)
|
||||
|
||||
> **Note**: You can still use `docker push` to push pre-built images to
|
||||
repositories with Automated Builds configured.
|
||||
|
||||
|
||||
|
||||
## Configure automated build settings
|
||||
|
||||
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.
|
||||
|
||||
Builds can be added to existing repositories, or added when you create a repository.
|
||||
|
||||
1. From the **Repositories** section, click into a repository to view its details.
|
||||
|
||||
2. Click the **Builds** tab.
|
||||
|
||||
3. If you are setting up automated builds for the first time, select
|
||||
the code repository service where the image's source code is stored.
|
||||
|
||||
Otherwise, if you are editing the build settings for an existing automated
|
||||
build, click **Configure automated builds**.
|
||||
|
||||
4. Select the **source repository** to build the Docker images from.
|
||||
|
||||
You might need to specify an organization or user (the _namespace_) from the
|
||||
source code provider. Once you select a namespace, its source code
|
||||
repositories appear in the **Select repository** dropdown list.
|
||||
|
||||
5. Optionally, enable [autotests](automated-testing.md#enable-automated-tests-on-a-repository).
|
||||
|
||||
6. Review the default **Build Rules**, and optionally click the
|
||||
**plus sign** to add and configure more build rules.
|
||||
|
||||
_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`.
|
||||
|
||||
7. 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 is not pushed to the repository.
|
||||
|
||||
8. For each branch or tag, enable or disable the **Build Caching** toggle.
|
||||
|
||||
[Build caching](/engine/userguide/eng-image/dockerfile_best-practices/#/build-cache) can save time if you are building a large image frequently or have
|
||||
many dependencies. You might want to leave build caching disabled to
|
||||
make sure all of your dependencies are resolved at build time, or if
|
||||
you have a large layer that is quicker to build locally.
|
||||
|
||||
9. Click **Save** to save the settings, or click **Save and build** to save and
|
||||
run an initial test.
|
||||
|
||||
A Webhook is automatically added to your source code repository to notify
|
||||
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
|
||||
`latest`. You
|
||||
|
||||
In the **Build Rules** section, enter one or more sources to build.
|
||||
|
||||
For each source:
|
||||
|
||||
* Select the **Source type** to build either a **tag** or a
|
||||
**branch**. This tells the build system what to look for in the source code
|
||||
repository.
|
||||
|
||||
* 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
|
||||
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](automated-build.md#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](automated-build.md#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)
|
||||
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
|
||||
then entering a variable name and the value.
|
||||
|
||||
When you set variable values from the Docker Hub UI, they can be used by the
|
||||
commands you set in `hooks` files, but they are stored so that only users who
|
||||
have `admin` access to the Docker Hub repository can see their values. This
|
||||
means you can use them to safely store access tokens or other information that
|
||||
should remain secret.
|
||||
|
||||
> **Note**: The variables set on the build configuration screen are used during
|
||||
the build processes _only_ and should not be 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 click a build job to view its build report. The
|
||||
build report shows information about the build job including the source
|
||||
repository and branch (or tag), the build duration, creation time and location,
|
||||
and the user namespace the build occurred in.
|
||||
|
||||
|
||||
|
||||
## Cancel or retry a build
|
||||
|
||||
While a build is queued 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** button from the build report page, or from the Timeline tab's logs
|
||||
display for the build.
|
||||
|
||||
|
||||
|
||||
If a build fails, a **Retry** icon appears next to the build report line on the
|
||||
General and Builds tabs, and 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.
|
||||
|
||||
|
||||
## Disable an automated build
|
||||
|
||||
Automated builds are enabled per branch or tag, and can be disabled and
|
||||
re-enabled easily. 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 does not disable [autotests](automated-testing.md).
|
||||
|
||||
To disable an automated build:
|
||||
|
||||
1. From the **Repositories** page, click into a repository, and click 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.
|
||||
|
||||
The toggle turns gray when disabled.
|
||||
|
||||
5. Click **Save** to save your changes.
|
||||
|
||||
## 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.
|
||||
|
||||
All of these options are available from the **Build configuration** screen for
|
||||
each repository. Click **Repositories** from the left navigation, click the name
|
||||
of the repository you want to edit, click the **Builds** tab, and click
|
||||
**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.
|
||||
|
||||
2. Select the **Source type** to build: either a **tag** or a **branch**.
|
||||
|
||||
This tells the build system what type of source to look for in the code
|
||||
repository.
|
||||
|
||||
3. Enter the name of the **Source** branch or tag you want to build.
|
||||
|
||||
You can enter a name, or use a regex to match which source branch or tag
|
||||
names to build. To learn more, see
|
||||
[regexes](automated-build.md#regexes-and-automated-builds).
|
||||
|
||||
4. 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](automated-build.md#regexes-and-automated-builds).
|
||||
|
||||
5. Repeat steps 2 through 4 for each new build rule you set up.
|
||||
|
||||
### Set the build context and Dockerfile location
|
||||
|
||||
Depending on how the files are arranged 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 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**: If you delete the default path `/` from the **Build context** field and leave it blank, the build system uses the path to the Dockerfile as the build context. However, to avoid confusion we recommend that you specify the complete path.
|
||||
|
||||
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.)
|
||||
|
||||
### 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 is applied to the built image.
|
||||
|
||||
You can use the variable `{sourceref}` to use the branch or tag name that
|
||||
matched the regex in the Docker tag applied to the resulting built image. (The
|
||||
variable includes the whole source name, not just the portion that matched the
|
||||
regex.) You can also use up to nine regular expression capture groups
|
||||
(expressions enclosed in parentheses) to select a source to build, and reference
|
||||
these in the Docker Tag field using `{\1}` through `{\9}`.
|
||||
|
||||
**Regex example: build from version number branch and tag with version number**
|
||||
|
||||
You might want to automatically build any branches that end with a number
|
||||
formatted like a version number, and tag their resulting Docker images using a
|
||||
name that incorporates that branch name.
|
||||
|
||||
To do this, specify a `branch` build with the regex `/[0-9.]+$/` in the
|
||||
**Source** field, and use the formula `version-{sourceref}` in the **Docker
|
||||
tag** field.
|
||||
|
||||
<!-- Capture groups Not a priority
|
||||
#### Regex example: build from version number branch and tag with version number
|
||||
|
||||
You could also use capture groups to build and label images that come from various sources. For example, you might have
|
||||
|
||||
`/(alice|bob)-v([0-9.]+)/` -->
|
||||
|
||||
### Create multiple Docker tags from a single build
|
||||
|
||||
By default, each build rule builds a source branch or tag into a Docker image,
|
||||
and then tags that image with a single tag. However, you can also create several
|
||||
tagged Docker images from a single build rule.
|
||||
|
||||
To create multiple tags from a single build rule, enter a comma-separated list
|
||||
of tags in the **Docker tag** field in the build rule. If an image with that tag
|
||||
already exists, Docker Hub overwrites the image when the build completes
|
||||
successfully. If you have automated tests configured, the build must pass these
|
||||
tests as well before the image is overwritten. You can use both regex references
|
||||
and plain text values in this field simultaneously.
|
||||
|
||||
For example if you want to update the image tagged with `latest` at the same
|
||||
time as you a tag an image for a specific version, you could enter
|
||||
`{sourceref},latest` in the Docker Tag field.
|
||||
|
||||
If you need to update a tag _in another repository_, use [a post_build hook](advanced.md#push-to-multiple-repos) to push to a second repository.
|
||||
|
||||
## 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](automated-build.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](automated-build.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 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
|
||||
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 |
|
||||
| --------------------- | ---- | ----- | ----- | ----- |
|
||||
| view build details | x | x | x | x |
|
||||
| start, cancel, retry | | x | x | x |
|
||||
| edit build settings | | | x | x |
|
||||
| delete build | | | | x |
|
||||
|
||||
### Service users for team autobuilds
|
||||
|
||||
> **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
|
||||
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, we recommend creating a dedicated service account
|
||||
(or "machine user") 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 are not exposed to an entire organization.
|
||||
|
||||
This service account should have access to any repositories to be built,
|
||||
and must have administrative access to the source code repositories so it can
|
||||
manage deploy keys. If needed, you can limit this account to only a specific
|
||||
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.
|
||||
|
||||
1. Create a service user account on your source provider, and generate SSH keys for it.
|
||||
2. Create a "build" team in your organization.
|
||||
3. Ensure that the new "build" team has access to each repository and submodule you need to build.
|
||||
|
||||
Go to the repository's **Settings** page. On Github, add the new "build" team to the list of **Collaborators and Teams**. On Bitbucket, add the "build" team to the list of approved users on the **Access management** screen.
|
||||
|
||||
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.
|
||||
|
||||
> **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](automated-build.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).
|
||||
|
||||
### Set up builder nodes
|
||||
|
||||
If you are building on your own infrastructure, you can run the build process on
|
||||
specific nodes by adding the `builder` label to them. If no builder nodes are
|
||||
specified, the build containers are deployed using an "emptiest node" strategy.
|
||||
|
||||
You can also limit the number of concurrent builds (including `autotest` builds)
|
||||
on a specific node by using a `builder=n` tag, where the `n` is the number of
|
||||
builds to allow. For example a node tagged with `builder=5` only allows up to
|
||||
five concurrent builds or autotest-builds at the same time.
|
||||
|
||||
### Autoredeploy services on successful build
|
||||
|
||||
You can configure your services to automatically redeploy once the build
|
||||
succeeds. [Learn more about autoredeploy](../apps/auto-redeploy.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
|
||||
does not push the resulting image to Docker Hub or the external registry.
|
||||
|
|
|
|||
|
|
@ -1,31 +1,30 @@
|
|||
---
|
||||
description: Link to your source code repository
|
||||
keywords: sourcecode, github, bitbucket
|
||||
description: Link to GitHub and BitBucket
|
||||
keywords: Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, documentation, trusted, builds, trusted builds, automated builds, GitHub
|
||||
title: Configure Automated Builds from GitHub and BitBucket
|
||||
redirect_from:
|
||||
- /docker-cloud/tutorials/link-source/
|
||||
- /docker-hub/github/
|
||||
- /docker-hub/bitbucket/
|
||||
- /docker-cloud/builds/link-source/
|
||||
title: Link Docker Hub to a source code provider
|
||||
---
|
||||
|
||||
To automate building of your images, you link to your hosted source
|
||||
code service to your Docker Hub repository so that it can access your source code
|
||||
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.
|
||||
|
||||
If you only push pre-built images to Docker Hub's registry, you do not
|
||||
need to link your source code provider.
|
||||
|
||||
> **Note**: If you are linking a source code provider to create autobuilds for a team, follow the instructions to [create a service account](automated-build.md#service-users-for-team-autobuilds) for the team before linking the account as described below.
|
||||
|
||||
## Link to a GitHub user account
|
||||
|
||||
1. Click **Settings** in the top right dropdown menu.
|
||||
1. Click **Settings** in the top-right dropdown navigation.
|
||||
|
||||
2. Click or scroll down to **Source providers**.
|
||||
2. Click or scroll down to **Linked Accounts**.
|
||||
|
||||
3. Click the plug icon for the source provider you want to link.
|
||||
|
||||
|
||||
|
||||
|
||||
4. Review the settings for the **Docker Hub Builder** OAuth application.
|
||||
|
||||
|
|
@ -38,15 +37,29 @@ need to link your source code provider.
|
|||
|
||||
5. Click **Authorize application** to save the link.
|
||||
|
||||
You are now ready to create a new image!
|
||||
## Link to a Bitbucket user account
|
||||
|
||||
1. Log in to Docker Hub using your Docker ID.
|
||||
|
||||
2. Click **Settings** in the top-right dropdown navigation.
|
||||
|
||||
3. Scroll to the **Linked Accounts** section.
|
||||
|
||||
4. Click the plug icon for the source provider you want to link.
|
||||
|
||||
|
||||
|
||||
5. If necessary, log in to Bitbucket.
|
||||
|
||||
6. 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 **Settings** in the top right dropdown menu, and click or scroll to the
|
||||
**Source providers** section.
|
||||
1. Click **Settings** in the top-right dropdown navigation, and click or scroll to the
|
||||
**Linked Accounts** section.
|
||||
|
||||
2. Click the plug icon next to the source provider you want to remove.
|
||||
|
||||
|
|
@ -57,7 +70,6 @@ from Docker Hub, *and* from your GitHub account.
|
|||
4. Go to your GitHub account's **Settings** page.
|
||||
|
||||
5. Click **OAuth applications** in the left navigation bar.
|
||||
|
||||
|
||||
6. Click **Revoke** next to the Docker Hub Builder application.
|
||||
|
||||
|
|
@ -99,6 +111,7 @@ section at the lower left.
|
|||
6. Click **Grant access** next to the organization.
|
||||
|
||||
|
||||
|
||||
### Revoke access to a GitHub organization
|
||||
|
||||
To revoke Docker Hub's access to an organization's GitHub repositories:
|
||||
|
|
@ -108,31 +121,15 @@ To revoke Docker Hub's access to an organization's GitHub repositories:
|
|||
3. From the Organization Profile menu, click **Third-party access**.
|
||||
The page displays a list of third party applications and their access status.
|
||||
4. Click the pencil icon next to Docker Hub Builder.
|
||||
|
||||
5. On the next page, click **Deny access**.
|
||||
|
||||
## Link to a Bitbucket user account
|
||||
|
||||
1. Log in to Docker Hub using your Docker ID.
|
||||
|
||||
2. Click the gear icon in the left navigation to go to your **Settings**.
|
||||
|
||||
3. Scroll to the **Source providers** section.
|
||||
|
||||
4. Click the plug icon for the source provider you want to link.
|
||||
|
||||
|
||||
|
||||
5. If necessary, log in to Bitbucket.
|
||||
|
||||
6. On the page that appears, click **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.
|
||||
|
||||
1. From your **Settings** page, click **Source providers**
|
||||
1. Find **Settings** in the top-right dropdown navigation, and scroll to **Linked Accounts**
|
||||
|
||||
2. Click the plug icon next to the source provider you want to remove.
|
||||
|
||||
|
|
@ -140,7 +137,7 @@ unlink it both from Docker Hub, *and* from your Bitbucket account.
|
|||
however access may not have been revoked. You can use this to _temporarily_
|
||||
disable a linked source code provider account.
|
||||
|
||||
4. Go to your Bitbucket account and click the user menu icon in the top right corner.
|
||||
4. Go to your Bitbucket account and click the user menu icon in the top-right corner.
|
||||
|
||||
5. Click **Bitbucket settings**.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
description: Docker Hub frequently asked questions
|
||||
description: Publisher & Certified Content FAQs
|
||||
keywords: Docker, docker, store, purchase images
|
||||
title: Docker Hub Customer FAQs
|
||||
title: Docker Hub Publisher & Certified Content FAQs
|
||||
redirect_from:
|
||||
- /docker-store/customer_faq/
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
description: Docker Hub programs and policies for publishers
|
||||
keywords: Docker, docker, store, publishers, publish images
|
||||
title: Docker Hub overview
|
||||
title: Publisher & Certified Content Overview
|
||||
---
|
||||
|
||||
Independent Software Vendors (ISVs) can utilize Docker Hub to distribute and
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
description: Docker Hub frequently asked questions
|
||||
description: Docker Hub frequently asked questions for publishers
|
||||
keywords: Docker, docker, hub, purchase images
|
||||
title: Docker Hub Publisher FAQs
|
||||
redirect_from:
|
||||
|
|
|
|||
Loading…
Reference in New Issue