@@ -5,73 +5,35 @@ info: To determine the technical writer assigned to the Stage/Group associated w
...
@@ -5,73 +5,35 @@ info: To determine the technical writer assigned to the Stage/Group associated w
type:index, concepts, howto
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
A cache is one or more files that a job downloads and saves. Subsequent jobs that use
when your jobs are running.
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
To learn how to define the cache in your `.gitlab-ci.yml` file,
content of a previous job. Use caching when you are
see the [`cache` reference](../yaml/README.md#cache).
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 at the project
## How cache is different from artifacts
level by default. Caches are not shared across projects.
Make sure you read the [`cache` reference](../yaml/README.md#cache) to learn
Use cache for dependencies, like packages you download from the internet.
how it is defined in `.gitlab-ci.yml`.
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
Use artifacts to pass intermediate build results between stages.
be overwritten because caches are restored before artifacts.
Artifacts are generated by a job, stored in GitLab, and can be downloaded.
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.
You can define an [expiry time](../yaml/README.md#artifactsexpire_in) so artifacts
- You can define artifacts per job. Subsequent jobs in later stages of the same
are deleted after a defined time. Use [dependencies](../yaml/README.md#dependencies)
pipeline can use them.
to control which jobs fetch the artifacts.
- You can't use the artifacts in a different pipeline.
Artifacts can also be used to make files available for download after a pipeline
Artifacts expire after 30 days unless you define an [expiration time](../yaml/README.md#artifactsexpire_in).
completes, like a build image.
Use [dependencies](../yaml/README.md#dependencies) to control which jobs fetch the artifacts.
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).
Both artifacts and caches define their paths relative to the project directory, and
Both artifacts and caches define their paths relative to the project directory, and
can't link to files outside it.
can't link to files outside it.
...
@@ -83,8 +45,7 @@ use one or more of the following:
...
@@ -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
-[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.
