<commit_before># Cache dependencies in GitLab CI/CD

GitLab CI/CD provides a caching mechanism that can be used to save time
when your jobs are running.

Caching is about speeding the time a job is executed by reusing the same
content of a previous job. It can be particularly useful when your are
developing software that depends on other libraries which are fetched via the
internet during build time.

If caching is enabled, it's shared between pipelines and jobs by default,
starting from GitLab 9.0.

Make sure you read the [`cache` reference](../yaml/README.md#cache) to learn
how it is defined in `.gitlab-ci.yml`.

## Good caching practices

We have the cache from the perspective of the developers (who consume a cache
within the job) and the cache from the perspective of the Runner. Depending on
which type of Runner you are using, cache can act differently.

From the perspective of the developer, to ensure maximum availability of the
cache, when declaring `cache` in your jobs, use one or a mix of the following:

- [Tag your Runners](../runners/README.md#using-tags) and use the tag on jobs
  that share their cache.
- [Use sticky Runners](../runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)
  that will be only available to a particular project.
- [Use a `key`](../yaml/README.md#cache-key) that fits your workflow (e.g.,
  different caches on each branch). For that, you can take advantage of the
  [CI/CD predefined variables](../variables/README.md#predefined-variables-environment-variables).

TIP: **Tip:**
Using the same Runner for your pipeline, is the most simple and efficient way to
cache files in one stage or pipeline, and pass this cache to subsequent stages
or pipelines in a guaranteed manner.

From the perspective of the Runner, in order for cache to work effectively, one
of the following must be true:

- Use a single Runner for all your jobs
- Use multiple Runners (in autoscale mode or not) that use
  [distributed caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching),
  where the cache is stored in S3 buckets (like shared Runners on GitLab.com)
- Use multiple Runners (not in autoscale mode) of the same architecture that
  share a common network-mounted directory (using NFS or something similar)
  where the cache will be stored

TIP: **Tip:**
Read about the [availability of the cache](#availability-of-the-cache)
to learn more about the internals and get a better idea how cache works.

### Sharing caches across the same branch

Define a cache with the `key: ${CI_COMMIT_REF_SLUG}` so that jobs of each
branch always use the same cache:

```yaml
cache:
  key: ${CI_COMMIT_REF_SLUG}
```

While this feels like it might be safe from accidentally overwriting the cache,
it means merge requests get slow first pipelines, which might be a bad
developer experience. The next time a new commit is pushed to the branch, the
cache will be re-used.

To enable per-job and per-branch caching:

```yaml
cache:
  key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"
```

To enable per-branch and per-stage caching:

```yaml
cache:
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"
```

### Sharing caches across different branches

If the files you are caching need to be shared across all branches and all jobs,
you can use the same key for all of them:

```yaml
cache:
  key: one-key-to-rull-them-all
```

To share the same cache between branches, but separate them by job:

```yaml
cache:
  key: ${CI_JOB_NAME}
```

### Disabling cache on specific jobs

If you have defined the cache globally, it means that each job will use the
same definition. You can override this behavior per-job, and if you want to
disable it completely, use an empty hash:<commit_msg>Fix typo in LOTR reference in caching documentation<commit_after># Cache dependencies in GitLab CI/CD

GitLab CI/CD provides a caching mechanism that can be used to save time
when your jobs are running.

Caching is about speeding the time a job is executed by reusing the same
content of a previous job. It can be particularly useful when your are
developing software that depends on other libraries which are fetched via the
internet during build time.

If caching is enabled, it's shared between pipelines and jobs by default,
starting from GitLab 9.0.

Make sure you read the [`cache` reference](../yaml/README.md#cache) to learn
how it is defined in `.gitlab-ci.yml`.

## Good caching practices

We have the cache from the perspective of the developers (who consume a cache
within the job) and the cache from the perspective of the Runner. Depending on
which type of Runner you are using, cache can act differently.

From the perspective of the developer, to ensure maximum availability of the
cache, when declaring `cache` in your jobs, use one or a mix of the following:

- [Tag your Runners](../runners/README.md#using-tags) and use the tag on jobs
  that share their cache.
- [Use sticky Runners](../runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)
  that will be only available to a particular project.
- [Use a `key`](../yaml/README.md#cache-key) that fits your workflow (e.g.,
  different caches on each branch). For that, you can take advantage of the
  [CI/CD predefined variables](../variables/README.md#predefined-variables-environment-variables).

TIP: **Tip:**
Using the same Runner for your pipeline, is the most simple and efficient way to
cache files in one stage or pipeline, and pass this cache to subsequent stages
or pipelines in a guaranteed manner.

From the perspective of the Runner, in order for cache to work effectively, one
of the following must be true:

- Use a single Runner for all your jobs
- Use multiple Runners (in autoscale mode or not) that use
  [distributed caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching),
  where the cache is stored in S3 buckets (like shared Runners on GitLab.com)
- Use multiple Runners (not in autoscale mode) of the same architecture that
  share a common network-mounted directory (using NFS or something similar)
  where the cache will be stored

TIP: **Tip:**
Read about the [availability of the cache](#availability-of-the-cache)
to learn more about the internals and get a better idea how cache works.

### Sharing caches across the same branch

Define a cache with the `key: ${CI_COMMIT_REF_SLUG}` so that jobs of each
branch always use the same cache:

```yaml
cache:
  key: ${CI_COMMIT_REF_SLUG}
```

While this feels like it might be safe from accidentally overwriting the cache,
it means merge requests get slow first pipelines, which might be a bad
developer experience. The next time a new commit is pushed to the branch, the
cache will be re-used.

To enable per-job and per-branch caching:

```yaml
cache:
  key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"
```

To enable per-branch and per-stage caching:

```yaml
cache:
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"
```

### Sharing caches across different branches

If the files you are caching need to be shared across all branches and all jobs,
you can use the same key for all of them:

```yaml
cache:
  key: one-key-to-rule-them-all
```

To share the same cache between branches, but separate them by job:

```yaml
cache:
  key: ${CI_JOB_NAME}
```

### Disabling cache on specific jobs

If you have defined the cache globally, it means that each job will use the
same definition. You can override this behavior per-job, and if you want to
disable it completely, use an empty hash:
{'fraction_non_alphanumeric': 0.07186422699549191, 'fraction_numerical': 0.0007955449482895784, 'mean_word_length': 4.319464033850494, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5488607', 'n_tokens_mistral': 2186, 'n_tokens_neox': 2076, 'n_words': 1086}