.gitlab-ci.yml Part Six – Basics Of Cache Artifacts Dependencies

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In the last blog post, we have discussed .gitlab-ci.yml features like environment, need, retry, timeout and parallel.

https://cloudaffaire.com/gitlab-ci-yml-part-five-basics-of-environment-need-retry-timeout-parallel/

In this blog post, we will discuss .gitlab-ci.yml features like cache, artifacts and dependencies.

cache:

cache is used to specify a list of files and directories which should be cached between jobs. You can only use paths that are within the local working copy. If cache is defined outside the scope of jobs, it means it is set globally and all jobs will use that definition. Cache supports below configuration parameters:

• cache:paths: Use the paths directive to choose which files or directories will be cached. Paths are relative to the project directory ($CI_PROJECT_DIR) and cannot directly link outside it.
• cache:key: The key directive allows you to define the affinity of caching between jobs, allowing to have a single cache for all jobs, cache per-job, cache per-branch or any other way that fits your workflow. This way, you can fine tune caching, allowing you to cache data between different jobs or even different branches.
• cache:key:files: The cache:key:files keyword extends the cache:key functionality by making it easier to reuse some caches, and rebuild them less often, which will speed up subsequent pipeline runs. When you include cache:key:files, you must also list the project files that will be used to generate the key, up to a maximum of two files.
• cache:key:prefix: The prefix parameter adds extra functionality to key:files by allowing the key to be composed of the given prefix combined with the SHA computed for cache:key:files.
• cache:untracked: Set untracked: true to cache all files that are untracked in your Git repository.
• cache:policy: The default behaviour of a caching job is to download the files at the start of execution, and to re-upload them at the end. This allows any changes made by the job to be persisted for future runs, and is known as the pull-push cache policy.

artifacts:

artifacts is used to specify a list of files and directories which should be attached to the job when it succeeds, fails, or always. The artifacts will be sent to GitLab after the job finishes and will be available for download in the GitLab UI. Artifacts supports below configuration parameter:

• artifacts:path: Paths are relative to the project directory ($CI_PROJECT_DIR) and cannot directly link outside it.
• artifacts:expose_as: The expose_as keyword can be used to expose job artifacts in the merge request UI.
• artifacts:name: The name directive allows you to define the name of the created artifacts archive. That way, you can have a unique name for every archive which could be useful when you’d like to download the archive from GitLab.
• artifacts:untracked: artifacts:untracked is used to add all Git untracked files as artifacts (along to the paths defined in artifacts:paths).
• artifacts:when: artifacts:when is used to upload artifacts on job failure or despite the failure. artifacts:when can have on_success, on_failure and always as values.
• artifacts:expire_in: expire_in allows you to specify how long artifacts should live before they expire and are therefore deleted, counting from the time they are uploaded and stored on GitLab. f the expiry time is not defined, it defaults to the instance wide setting (30 days by default, forever on GitLab.com).
• artifacts:reports: The reports keyword is used for collecting test reports, code quality reports, and security reports from jobs. It also exposes these reports in GitLab’s UI (merge requests, pipeline views, and security dashboards).

You can download artifacts from the pipeline.

cache vs 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 the Runner is installed and uploaded to S3 if distributed cache is enabled.
• 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 the subsequent jobs of that currently active pipeline.
• Are always uploaded to GitLab (known as coordinator).
• Can have an expiration value for controlling disk usage (30 days by default).

dependencies:

By default, all artifacts from all previous stages are passed, but you can use the dependencies parameter to define a limited list of jobs (or no jobs) to fetch artifacts from. To use this feature, define dependencies in context of the job and pass a list of all previous jobs from which the artifacts should be downloaded. You can only define jobs from stages that are executed before the current one. An error will be shown if you define jobs from the current stage or next ones. Defining an empty array will skip downloading any artifacts for that job. The status of the previous job is not considered when using dependencies, so if it failed or it is a manual job that was not run, no error occurs.

Hope you enjoyed this article. In the next blog post, we will continue our discussion .gitlab-ci.yml.

To get more details on GitLab you can follow the below link.

https://docs.gitlab.com/ee/README.html

To Get more details on Git you can follow the below links.

https://cloudaffaire.com/category/devops/git/

https://git-scm.com/doc