mirror of https://github.com/docker/docs.git
add classic automated build explanation
This commit is contained in:
parent
f6bbf912db
commit
f581dca6fb
|
@ -0,0 +1,56 @@
|
|||
---
|
||||
description: Explains the differece between Classic and Enhanced Automated Builds
|
||||
keywords: automated, build, images
|
||||
title: Classic vs Enhanced Automated Builds
|
||||
---
|
||||
|
||||
With the launch of the new Docker Hub, we are introducing Enhanced Automated Build.
|
||||
|
||||
Automated builds created using the old Docker Hub are now Classic Automated Builds, and automated builds created
|
||||
using the old Docker Cloud are now Enhanced Automated Build.
|
||||
|
||||
All new automated builds created going forward will be Enhanced Automated Build. If you are creating an Enhanced
|
||||
Automated Build for the first time, see [docs](index.md#configure-automated-build-settings).
|
||||
|
||||
In the coming months, we will gradually convert Classic Automated Builds into Enhanced Automated Builds. This should
|
||||
be a seamless process for most users.
|
||||
|
||||
|
||||
## Managing Classic Automated Builds
|
||||
|
||||
You can manage both Classic and Enhanced Automated Builds from the **Builds** tab
|
||||
|
||||
Repository with Classic Automated Build:
|
||||
|
||||

|
||||
|
||||
You can configure build settings pretty much the same way as the old Docker Hub.
|
||||
|
||||
If you have previously created an automated build in both the old Docker Hub and Docker Cloud, you can switch between
|
||||
Classic and Enhanced Automated Builds.
|
||||
|
||||
Enhanced Automated Build is displayed by default. You can switch to Classic Automated Build by clicking on this link at the top
|
||||
|
||||

|
||||
|
||||
Likewise, you can switch back to Enhanced Automated Build by clicking on this link at the top
|
||||
|
||||

|
||||
|
||||
|
||||
## Frequently asked questions
|
||||
|
||||
1. I've previously linked my Github/Bitbucket account in the old Docker Hub. Do I need to re-link it?
|
||||
|
||||
Unless you've linked your Github/Bitbucket account with the old Docker Cloud previously, you will need to [re-link](link-source.md) it
|
||||
with the new Docker Hub.
|
||||
|
||||
2. What happens to my old Docker Hub automated builds?
|
||||
|
||||
They are now Classic Automated Builds. There are no functional difference with the old automated builds and everything
|
||||
(build triggers, existing build rules etc) should continue to work seamlessly
|
||||
|
||||
3. Is it possible to convert an existing Classic Automated Build into Enhanced Automated Build?
|
||||
|
||||
This is currently unsupported. However, we are working to transition all builds into Enhanced Automated Build in
|
||||
the coming months.
|
Binary file not shown.
After Width: | Height: | Size: 99 KiB |
Binary file not shown.
After Width: | Height: | Size: 56 KiB |
Binary file not shown.
After Width: | Height: | Size: 45 KiB |
|
@ -8,6 +8,7 @@ redirect_from:
|
|||
title: Set up Automated builds
|
||||
---
|
||||
|
||||
|
||||
## How Automated Builds work
|
||||
|
||||
Docker Hub can automatically build images from source code in an external
|
||||
|
@ -18,21 +19,24 @@ 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.
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
> **Note**: Automated builds created with the old Docker Hub are
|
||||
now Classic Automated Builds. [Learn more](classic-vs-enhanced.md)
|
||||
|
||||
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
|
||||
|
@ -45,7 +49,8 @@ Builds can be added to existing repositories, or added when you create a reposit
|
|||
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.
|
||||
the code repository service (Github or Bitbucket) where the image's source code is stored.
|
||||
You might redirected to the settings page to [link](link-source.md) the code repository service.
|
||||
|
||||
Otherwise, if you are editing the build settings for an existing automated
|
||||
build, click **Configure automated builds**.
|
||||
|
@ -395,22 +400,6 @@ 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
|
||||
|
@ -418,4 +407,7 @@ 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.
|
||||
does not push the resulting image to Docker Hub.
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue