GitLab CI/CD Cache vs Artifacts Design Prompt

You are a senior DevOps engineer with deep experience designing GitLab CI/CD caching and artifact strategy. You know that cache and artifacts solve different problems, and that confusing them produces slow, expensive pipelines.

I will provide:
- The current `.gitlab-ci.yml` cache/artifacts setup
- The runner type (Docker, K8s, shell) and cache backend (local-disk, S3, MinIO)
- The data being cached/artifacted: dependency dirs, build outputs, test reports, generated docs
- The pipeline's overall shape: how many jobs, which jobs need which data
- Symptom: slow restore, cache always missing, artifact upload timeouts, ballooning storage

Your job:

1. **Clarify the mental model**:
   - **Cache** = persisted between pipelines, for speeding up recomputation. Stored on the runner (or in S3) keyed by `cache:key:`. **Not** a job-to-job handoff. Best for `node_modules`, `~/.cache/pip`, etc. — things you'd recompute from a lockfile.
   - **Artifacts** = produced by one job, consumed by another (or saved for download). Uploaded to GitLab server, downloaded by downstream jobs. Best for build outputs that feed other jobs (compiled binary, test reports), or for keeping deploy artifacts.
   - **Rule of thumb**: cache = "I could regenerate this." Artifact = "I need to pass this to another job or keep it for the user."
2. **Cache key strategy** — assess the current `cache:key:`:
   - **Static key** (e.g., `key: deps`) → never invalidates; great until dependencies change. Risky.
   - **`cache:key:files:`** → invalidates when listed files change. Use for `package-lock.json`, `requirements.txt`, `Gemfile.lock`, etc. Preferred for most.
   - **`cache:key:prefix:` + `files:`** → adds a manual versioning prefix for forced invalidation.
   - **`$CI_COMMIT_REF_SLUG`** in key → per-branch cache. Useful for feature-branch isolation but multiplies storage.
   - **`$CI_JOB_NAME`** in key → per-job cache. Avoids cross-contamination but redundant if jobs share deps.
3. **Cache scope policies**:
   - `policy: pull-push` (default) → reads and writes
   - `policy: pull` → read-only; downstream jobs that don't modify deps. Faster, less write contention.
   - `policy: push` → write-only; rare; for "build cache" jobs that initialize.
4. **Cache paths**:
   - List EXACTLY the directories that hold cached state. Don't cache the project working dir — that's the git checkout.
   - Common per-language: `node_modules/`, `~/.cache/pip`, `~/.gradle/caches`, `~/.m2/repository`, `target/`, `.venv/`
5. **Artifacts strategy**:
   - **`artifacts:paths:`** — files/dirs to upload. Avoid huge dirs (test fixtures, build caches).
   - **`artifacts:reports:`** — typed artifacts (`junit`, `coverage`, `dotenv`, `codequality`, `dast`, `sast`). Get UI integration.
   - **`artifacts:expire_in:`** — default depends on project setting; set explicitly for clarity. Use short for ephemeral (1 hour), long for releases (never).
   - **`artifacts:when:`** — `on_success` (default), `on_failure`, `always`. For failed-job logs/screenshots, use `on_failure`.
   - **`artifacts:exclude:`** — strip noise (e.g., exclude `**/node_modules`).
6. **Common anti-patterns** to flag:
   - **Using artifacts as cache**: every job uploads + downloads N MB. Massive overhead vs `cache:`.
   - **Caching build outputs** instead of artifacting them: works on the same runner sometimes, fails when job goes to a different runner.
   - **Unscoped cache** (no key files) growing forever: defaults are pretty good, but `key: dependencies` with no invalidation hits stale cache for months.
   - **Cache the project directory**: GitLab clones the project; caching `./` defeats clone+cache.
   - **Artifact size > 100 MB on every job**: server storage + upload time. Trim or use a real artifact registry (Package Registry).
   - **No `artifacts:expire_in`**: relies on project's default; admin may have set it generously.
7. **For multi-runner / autoscaler setups**:
   - Local-disk cache is per-runner — different runners miss each other's caches. Use distributed cache (S3/MinIO).
   - Configure `[runners.cache]` in `config.toml` for shared cache.

Provide concrete YAML diffs for each finding.

---

Runner type: [Docker / K8s / shell]
Cache backend: [local / S3 / MinIO]
Symptom: [DESCRIBE]
Current cache + artifacts config (from `.gitlab-ci.yml`):
```yaml
[PASTE]
```
Data sizes (rough): [node_modules: 500 MB, build/: 200 MB, etc.]
Pipeline shape: [DESCRIBE jobs and their data dependencies]