DevOps / Gitlab Interview questions
How does GitLab cache artifacts between pipeline jobs?
GitLab distinguishes two related but different mechanisms: cache and artifacts, and mixing them up is a frequent source of slow or broken pipelines.
| Cache | Artifacts |
Meant to speed up jobs by reusing dependencies (like node_modules). | Meant to pass build output (like a compiled binary) to later stages or for download. |
| Not guaranteed to be available; best-effort. | Guaranteed to be passed to jobs in later stages that need them. |
| Scoped by a cache key, often the branch or lockfile hash. | Attached to a specific job run and browsable/downloadable from the UI. |
| Expires based on runner storage/cleanup policy. | Has a configurable expiry, default or explicit. |
test-job: stage: test cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ artifacts: paths: - dist/ expire_in: 1 week script: - npm ci - npm run build
Use cache for things that just save time if reused (and are fine to rebuild if missing), and artifacts for anything a later stage or a human actually depends on receiving, since GitLab treats artifact availability as part of the pipeline's contract rather than a best-effort optimization.
Which is guaranteed to be passed forward to a later stage that needs it?
Cache is best suited for:
More Related questions...
