The built image is then pushed to the Docker Cloud registry or to an external


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.

The first time you configure automated builds, a default tag mapping 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).

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

disabled will be built for test purposes (if enabled at the repository level), but not pushed.

10. For each branch or tag, enable or disable the **Build Caching** toggle.

[Build caching](https://docs.docker.com/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.

11. Click **Save** to save the settings, or click **Save and build** to save and

You can view a summary of the last five builds for a repository from the repository's **General** tab. You can also click **Timeline** to view a list of all active builds, and expand each build to see their real-time logs. 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.

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 will 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**.

You can configure your automated builds so that pushes to specific branches or tags will trigger a build.

1. In the **Tag mappings** 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 tag mapping you set up.

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.

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

This step is optional, but allows you to revoke the build-only keypair without removing other access.