Cache and artifacts management ​

##GitlabCI

https://docs.gitlab.com/ee/ci/caching/

Caching ​

A cache is one or more files saved from a job to be used later on in subsequent jobs and/or pipelines.

The idea is to save time in the build stages by storing dependencies that won't change often.

Cache key ​

The cache key is an unique identifier of the cache used to know which cache to store and retrieve from the runner. All jobs with the same cache key will use the same cache.

If a job uses cache but defines no cache key, it will use the default as the default cache key.

Because the cache is shared between jobs, be careful with the cache key if you're using different caches, or it might end up overwritten by accident.

Computing the cache key from one or more files ​

The cache key can be computed from one or more files, so that the cache get updated along with the file(s) listed.

Usually used with lockfiles generated by dependencies mamangement systems (npm, Poetry, maven...), that way it is possible to use differente caches depending on the branches/MR.

Artifacts ​

https://docs.gitlab.com/ee/ci/jobs/job_artifacts.html

Artifacts are files/folders created and outputed by a job.

They can be used to share intermediate build results between jobs, as well as with users through the UI.

Artifacts reports ​

Can be used to export some well identified artifacts. Some can be used to improve the informations displayed on MR UI.

Full list

Cache vs artifacts ​

The cache is meant to save dependencies like packages and build deps. It is stored on the runner, and can be distributed using S3 storage.

The artifacts are produced by jobs and can be used to pass intermediate build results between stages of the same pipelines. They are stored on Gitlab and can be viewed and downloaded from the interface/API (usually).

* only if the dependencies are identical ** only if the cache is not expired, hasn't been invalidated and the dependencies are identical