Fix missing build changes & toc fixes

2018-11-27 14:49:31 -05:00 · 2018-11-27 14:49:31 -05:00 · 1f5d8fdb3e
parent 893c82a11f
commit 1f5d8fdb3e
20 changed files with 459 additions and 720 deletions
--- a/_data/toc.yaml
+++ b/_data/toc.yaml
@ -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
+        title: Advanced Automated Builds
-      - path: /docker-hub/builds/github/
+      - path: /docker-hub/builds/link-source/
-        title: Connecting GitHub
+        title: Link to GitHub and BitBucket
-      - path: /docker-hub/builds/bitbucket/
+  - sectiontitle: Publisher & Certified Content
        title: Connecting BitBucket
  - sectiontitle: Publisher Images & Plugins
    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/
--- a/docker-hub/builds/automated-build.md
+++ b/docker-hub/builds/automated-build.md
@ -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.
 ![An automated build dashboard](images/build-dashboard.png)
 ## 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.
 ![screen showing a build report](images/build-report.png)
 ## 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.
 ![list of builds showing the cancel icon](images/build-cancelicon.png)
 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.
 ![Timeline view showing the retry build button](images/retry-build.png)
 > **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.
--- a/docker-hub/builds/bitbucket.md
+++ b/docker-hub/builds/bitbucket.md
@ -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**.
 ![authorized-services](images/authorized-services.png)
 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 &#x25BC;" 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.
 ![bitbucket-hooks](images/bitbucket-hook.png)
--- a/docker-hub/builds/github.md
+++ b/docker-hub/builds/github.md
@ -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 &ndash; 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".
 ![Check User access to GitHub](images/gh-check-user-org-dh-app-access.png)
 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.
 ![Check Docker Hub application access to Organization](images/gh-check-admin-org-dh-app-access.png)
 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:
 ![github-webhook-add](images/github-webhook-add.png)
 If configured correctly, you'll see this in the **Webhooks** view
 ![github-webhook](images/github-webhook.png)
--- a/docker-hub/builds/images/build-dashboard.png
+++ b/docker-hub/builds/images/build-dashboard.png
--- a/docker-hub/builds/images/build-report.png
+++ b/docker-hub/builds/images/build-report.png
--- a/docker-hub/builds/images/index-active.png
+++ b/docker-hub/builds/images/index-active.png
--- a/docker-hub/builds/images/index-dashboard.png
+++ b/docker-hub/builds/images/index-dashboard.png
--- a/docker-hub/builds/images/index-report.png
+++ b/docker-hub/builds/images/index-report.png
--- a/docker-hub/builds/images/link-source-github-ind-revoke.png
+++ b/docker-hub/builds/images/link-source-github-ind-revoke.png
--- a/docker-hub/builds/images/link-source-github-ind.png
+++ b/docker-hub/builds/images/link-source-github-ind.png
--- a/docker-hub/builds/images/link-source-github-org-lite.png
+++ b/docker-hub/builds/images/link-source-github-org-lite.png
--- a/docker-hub/builds/images/link-source-github-org.png
+++ b/docker-hub/builds/images/link-source-github-org.png
--- a/docker-hub/builds/images/link-source-unlink-github.png
+++ b/docker-hub/builds/images/link-source-unlink-github.png
--- a/docker-hub/builds/images/linking-connect-providers.png
+++ b/docker-hub/builds/images/linking-connect-providers.png
--- a/docker-hub/builds/index.md
+++ b/docker-hub/builds/index.md
@ -1,24 +1,421 @@
 ---
-description: Overview
+description: Set up Automated builds
-keywords: builds, images, Hub
+keywords: automated, build, images
 title: Overview
 notoc: true
 redirect_from:
 - /docker-cloud/feature-reference/automated-build/
 - /docker-cloud/builds/automated-build/
 - /docker-cloud/builds/
- /docker-cloud/builds/repos/
+title: Set up Automated builds
 - /docker-cloud/builds/push-images/
 ---
-Docker Hub provides a hosted registry service where you can create
+## How Automated Builds work
 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.
-You can build images manually, or set up automated builds to rebuild your Docker
+Docker Hub can automatically build images from source code in an external
-image on each `git push` to the source code.
+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)
+If you have automated tests configured, these run after building but before
-* [Automated Repository tests](automated-testing.md)
+pushing to the registry. You can use these tests to create a continuous
-* [Advanced options for Autobuild and Autotest](advanced.md)
+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
 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.
 ![Active Builds](images/index-active.png)
 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.
 ![Build Report](images/index-report.png)
 ## 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.
 ![list of builds showing the cancel icon](images/build-cancelicon.png)
 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.
 ![Timeline view showing the retry build button](images/retry-build.png)
 > **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.
--- a/docker-hub/builds/link-source.md
+++ b/docker-hub/builds/link-source.md
@ -1,31 +1,30 @@
 ---
-description: Link to your source code repository
+description: Link to GitHub and BitBucket
-keywords: sourcecode, github, 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
+To automate building and testing of your images, you link to your hosted source
-code service to your Docker Hub repository so that it can access your source code
+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.
-    ![Linking source providers](images/source-providers.png)
+    ![Linking source providers](images/linking-connect-providers.png)
 4. Review the settings for the **Docker Hub Builder** OAuth application.
    ![Granting access to GitHub account](images/link-source-github-ind.png)
@ -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.
    ![Linking Bitbucket](images/source-providers.png)
 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
+1. Click **Settings** in the top-right dropdown navigation, and click or scroll to the
-**Source providers** section.
+**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.
    ![Revoking access to GitHub account](images/link-source-github-ind-revoke.png)
 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.
    ![Granting access to GitHub organization manually](images/link-source-github-org.png)
 ### 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.
    ![Revoking access to GitHub organization](images/link-source-github-org-revoke.png)
 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.
    ![Linking Bitbucket](images/source-providers.png)
 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**.
--- a/docker-hub/publish/customer_faq.md
+++ b/docker-hub/publish/customer_faq.md
@ -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/
 ---
--- a/docker-hub/publish/index.md
+++ b/docker-hub/publish/index.md
@ -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
--- a/docker-hub/publish/publisher_faq.md
+++ b/docker-hub/publish/publisher_faq.md
@ -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: