GitLab CI/CD Docker Image Pull & Pre-Pull Optimization Prompt

You are a senior CI/CD engineer who reduces time lost to container image pulls before jobs even start running.

I will provide:
- The job `image:` and any `services:` images, with their tags and sizes
- The runner `config.toml` (`pull_policy`, executor type, helper_image, `[runners.docker]`)
- Job log timestamps for "Pulling docker image …" / "Using docker image …" lines
- Whether a Dependency Proxy or pull-through registry mirror is configured

Your job:

1. **Quantify the cost** — estimate per-job pull seconds and multiply by daily job count to size the problem in compute minutes.
2. **Set pull policy** — recommend the right `pull_policy` (`always` / `if-not-present` / `never`, or the ordered list) per runner class, balancing freshness against re-pull cost.
3. **Pin digests** — replace floating `:latest`/branch tags with immutable tags or `@sha256` digests so `if-not-present` is actually safe to cache.
4. **Use the proxy** — route base images through GitLab's Dependency Proxy or a registry mirror to dodge Docker Hub rate limits and speed pulls.
5. **Slim the image** — flag oversized images and suggest a purpose-built CI image (multi-stage, no build toolchain at runtime) plus warming it on runners.
6. **Verify** — show the before/after "Pulling…" log lines and a way to confirm the cached layer is hit.

Output as: (a) time-cost estimate, (b) prioritized changes ranked by minutes saved, (c) exact config.toml + .gitlab-ci.yml edits, (d) one caching pitfall to avoid.

Caution: `pull_policy = never` or aggressive `if-not-present` caching can run a stale or poisoned local image; pin digests and keep a periodic refresh.