Merge pull request #904 from jmwong/jmwong-consolidation-docs

add classic automated build explanation

_data/toc.yaml

@@ -3653,6 +3653,8 @@ manuals:
         title: Advanced Automated Builds
       - path: /docker-hub/builds/link-source/
         title: Link to GitHub and BitBucket
+      - path: /docker-hub/builds/classic
+        title: Classic Automated Builds
   - sectiontitle: Publisher & Certified Content
     section:
     - path: /docker-hub/publish/

docker-hub/builds/classic.md

@@ -0,0 +1,59 @@
+---
+description: Explains the difference between Classic and new Automated Builds
+keywords: automated, build, images
+title: Classic Automated Builds
+---
+
+With the launch of the new Docker Hub, we are introducing an improved Automated Build experience.
+
+Automated Builds created using an older version of Docker Hub are now labelled "Classic". 
+If you were using Docker Cloud to manage builds, your builds are already the latest version of Automated Builds.
+
+All automated builds created going forward will get the new experience. If you are creating a new
+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 new Automated Builds. This should
+be a seamless process for most users.
+
+
+## Managing Classic Automated Builds
+
+You can manage both Classic and new Automated Builds from the **Builds** tab
+
+Repository with Classic Automated Build:
+
+![A Classic Automated Build dashboard](images/classic-vs-new-classic-only.png)
+
+ Build settings can be configured similarly to those on 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 new Automated Builds.
+
+New 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-new-switch-to-classic.png)
+
+Likewise, you can switch back to new Automated Build by clicking on this link at the top
+
+![Switching to new Automated Build](images/classic-vs-new-switch-to-new.png)
+
+
+## Frequently Asked Questions
+
+
+**Q: I've previously linked my Github/Bitbucket account in the old Docker Hub. Why do I need to re-link it?**
+
+A: The new Docker Hub uses a different permissions model. [Linking is only a few clicks by going to account settings](link-source.md).
+with the new Docker Hub.
+
+  > **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.
+
+**Q: What happens to automated builds I created in the old Docker Hub?**
+
+A: They are now Classic Automated Builds. There are no functional differences with the old automated builds and everything 
+(build triggers, existing build rules etc) should continue to work seamlessly.
+
+**Q: Is it possible to convert an existing Classic Automated Build?**
+
+A: This is currently unsupported. However, we are working to transition all builds into new experience in
+the coming months.

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.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.
+
+
+