@@ -5,73 +5,35 @@ info: To determine the technical writer assigned to the Stage/Group associated w
type:index, concepts, howto
---
# Cache dependencies in GitLab CI/CD
# Caching in GitLab CI/CD
GitLab CI/CD provides a caching mechanism that can be used to save time
when your jobs are running.
A cache is one or more files that a job downloads and saves. Subsequent jobs that use
the same cache don't have to download the files again, so they execute more quickly.
Caching is about speeding the time a job is executed by reusing the same
content of a previous job. Use caching when you are
developing software that depends on other libraries which are fetched via the
internet during build time.
To learn how to define the cache in your `.gitlab-ci.yml` file,
see the [`cache` reference](../yaml/README.md#cache).
If caching is enabled, it's shared between pipelines and jobs at the project
level by default. Caches are not shared across projects.
## How cache is different from artifacts
Make sure you read the [`cache` reference](../yaml/README.md#cache) to learn
how it is defined in `.gitlab-ci.yml`.
Use cache for dependencies, like packages you download from the internet.
Cache is stored where GitLab Runner is installed and uploaded to S3 if
[distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
## Cache vs artifacts
- You can define it per job by using the `cache:` keyword. Otherwise it is disabled.
- You can define it per job so that:
- Subsequent pipelines can use it.
- Subsequent jobs in the same pipeline can use it, if the dependencies are identical.
- You cannot share it between projects.
If you use cache and artifacts to store the same path in your jobs, the cache might
be overwritten because caches are restored before artifacts.
Don't use caching for passing artifacts between stages, as it is designed to store
runtime dependencies needed to compile the project:
-`cache`: **For storing project dependencies**
Caches can increase the speed of a given job in subsequent pipelines. You can
store downloaded dependencies so that they don't have to be fetched from the
internet again. Dependencies include things like npm packages, Go vendor packages, and so on.
You can configure a cache to pass intermediate build results between stages,
but you should use artifacts instead.
-`artifacts`: **Use for stage results that are passed between stages.**
Artifacts are files that are generated by a job so they can be stored and uploaded. You can
fetch and use artifacts in jobs in later stages of the same pipeline. You can't
create an artifact in a job in one stage, and use this artifact in a different job in
the same stage. This data is not available in different pipelines, but can be downloaded
from the UI.
If you download modules while building your application, you can declare them as
artifacts and subsequent stage jobs can use them.
Use artifacts to pass intermediate build results between stages.
Artifacts are generated by a job, stored in GitLab, and can be downloaded.
You can define an [expiry time](../yaml/README.md#artifactsexpire_in) so artifacts
are deleted after a defined time. Use [dependencies](../yaml/README.md#dependencies)
to control which jobs fetch the artifacts.
- You can define artifacts per job. Subsequent jobs in later stages of the same
pipeline can use them.
- You can't use the artifacts in a different pipeline.
Artifacts can also be used to make files available for download after a pipeline
completes, like a build image.
Caches:
- Are disabled if not defined globally or per job (using `cache:`).
- Are available for all jobs in your `.gitlab-ci.yml` if enabled globally.
- Can be used in subsequent pipelines by the same job in which the cache was created (if not defined globally).
- Are stored where GitLab Runner is installed **and** uploaded to S3 if [distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
- If defined per job, are used:
- By the same job in a subsequent pipeline.
- By subsequent jobs in the same pipeline, if they have identical dependencies.
Artifacts:
- Are disabled if not defined per job (using `artifacts:`).
- Can only be enabled per job, not globally.
- Are created during a pipeline and can be used by subsequent jobs in the same pipeline.
- Are always uploaded to GitLab (known as coordinator).
- Can have an expiration value for controlling disk usage (30 days by default).
Artifacts expire after 30 days unless you define an [expiration time](../yaml/README.md#artifactsexpire_in).
Use [dependencies](../yaml/README.md#dependencies) to control which jobs fetch the artifacts.
Both artifacts and caches define their paths relative to the project directory, and
can't link to files outside it.
...
...
@@ -83,8 +45,7 @@ use one or more of the following:
-[Tag your runners](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
GitLab provides a caching mechanism to speed up build times for your jobs by reusing previously downloaded dependencies. It's important to know the different between [cache and artifacts](../caching/index.md#cache-vs-artifacts) to make the best use of these features.
GitLab provides a caching mechanism to speed up build times for your jobs by reusing previously downloaded dependencies. It's important to know the different between [cache and artifacts](../caching/index.md#how-cache-is-different-from-artifacts) to make the best use of these features.
