Home Explore Blog Models CI



docker

2nd chunk of `content/manuals/build/cache/backends/gha.md`
ef53aef9cea0c2134c1cf72917ddb839cc6eda83b682f6fd0000000100000994
| `timeout`      | `cache-to`,`cache-from` | String      | `10m`                                          | Max duration for importing or exporting cache before it's timed out. |
| `repository`   | `cache-to`              | String      |                                                | GitHub repository used for cache storage.                            |
| `ghtoken`      | `cache-to`              | String      |                                                | GitHub token required for accessing the GitHub API.                  |


## Authentication

If the `url`, `url_v2` or `token` parameters are left unspecified, the `gha`
cache backend will fall back to using environment variables. If you invoke the
`docker buildx` command manually from an inline step, then the variables must
be manually exposed. Consider using the
[`crazy-max/ghaction-github-runtime`](https://github.com/crazy-max/ghaction-github-runtime),
GitHub Action as a helper for exposing the variables.

## Scope

Scope is a key used to identify the cache object. By default, it is set to
`buildkit`. If you build multiple images, each build will overwrite the cache
of the previous, leaving only the final cache.

To preserve the cache for multiple builds, you can specify this scope attribute
with a specific name. In the following example, the cache is set to the image
name, to ensure each image gets its own cache:

```console
$ docker buildx build --push -t <registry>/<image> \
  --cache-to type=gha,url=...,token=...,scope=image \
  --cache-from type=gha,url=...,token=...,scope=image .
$ docker buildx build --push -t <registry>/<image2> \
  --cache-to type=gha,url=...,token=...,scope=image2 \
  --cache-from type=gha,url=...,token=...,scope=image2 .
```

GitHub's [cache access restrictions](https://docs.github.com/en/actions/advanced-guides/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache),
still apply. Only the cache for the current branch, the base branch and the
default branch is accessible by a workflow.

### Using `docker/build-push-action`

When using the
[`docker/build-push-action`](https://github.com/docker/build-push-action), the
`url` and `token` parameters are automatically populated. No need to manually
specify them, or include any additional workarounds.

For example:

```yaml
- name: Build and push
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: "<registry>/<image>:latest"

Title: GitHub Actions Cache Authentication, Scope, and Usage with docker/build-push-action
Summary
This section details the authentication process for the GitHub Actions cache, emphasizing the use of environment variables and the `crazy-max/ghaction-github-runtime` action. It explains the importance of 'scope' for cache object identification, demonstrating how to prevent cache overwrites by assigning unique scopes to different builds. The section also covers how GitHub's cache access restrictions apply and simplifies the process when using the `docker/build-push-action`, where `url` and `token` parameters are automatically handled.