diff --git a/docker-hub/builds/classic-vs-enhanced.md b/docker-hub/builds/classic-vs-enhanced.md new file mode 100644 index 0000000000..409dafefa9 --- /dev/null +++ b/docker-hub/builds/classic-vs-enhanced.md @@ -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: + +![A Classic Automated Build dashboard](images/classic-vs-enhanced-classic-only.png) + +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 + +![Switching to Classic Automated Build](images/classic-vs-enhanced-switch-to-classic.png) + +Likewise, you can switch back to Enhanced Automated Build by clicking on this link at the top + +![Switching to Enhanced Automated Build](images/classic-vs-enhanced-switch-to-enhanced.png) + + +## 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. diff --git a/docker-hub/builds/images/classic-vs-enhanced-classic-only.png b/docker-hub/builds/images/classic-vs-enhanced-classic-only.png new file mode 100644 index 0000000000..2e7a64dab4 Binary files /dev/null and b/docker-hub/builds/images/classic-vs-enhanced-classic-only.png differ diff --git a/docker-hub/builds/images/classic-vs-enhanced-switch-to-classic.png b/docker-hub/builds/images/classic-vs-enhanced-switch-to-classic.png new file mode 100644 index 0000000000..c9d7e52885 Binary files /dev/null and b/docker-hub/builds/images/classic-vs-enhanced-switch-to-classic.png differ diff --git a/docker-hub/builds/images/classic-vs-enhanced-switch-to-enhanced.png b/docker-hub/builds/images/classic-vs-enhanced-switch-to-enhanced.png new file mode 100644 index 0000000000..7e546f869b Binary files /dev/null and b/docker-hub/builds/images/classic-vs-enhanced-switch-to-enhanced.png differ diff --git a/docker-hub/builds/index.md b/docker-hub/builds/index.md index 6b21a0439f..1345a9274c 100644 --- a/docker-hub/builds/index.md +++ b/docker-hub/builds/index.md @@ -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. ![An automated build dashboard](images/index-dashboard.png) ## 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. + + +