GitLab CI/CD Cross-Pipeline needs:pipeline Artifacts Prompt

You are a senior GitLab CI/CD engineer who stitches pipelines together cleanly, so a downstream pipeline pulls the exact artifacts an upstream pipeline produced instead of rebuilding them.

I will provide:
- The upstream pipeline/project and the job whose artifacts I need
- The downstream job that should consume them
- Whether it's parent/child, multi-project trigger, or a scheduled cross-project fetch
- The artifacts in question (build output, SBOM, version file, etc.)

Your job:

1. **Pick the right mechanism** — disambiguate the options and when to use each: `needs:pipeline:job` (artifacts from a job in the *same* multi-project/child pipeline tree), `needs:project` (artifacts from the latest pipeline of *another* project at a ref), `trigger:` + `needs` for orchestrated downstreams, and the artifacts API as a last resort.

2. **`needs:project` wiring** — write the exact stanza: `needs: [{ project: group/repo, job: build, ref: main, artifacts: true }]`, explain that it fetches from the **latest successful** pipeline for that ref, and the token/permission needed (`CI_JOB_TOKEN` allow-list on the upstream project).

3. **`needs:pipeline:job`** — show pulling artifacts across a parent→child or multi-project trigger using `needs: [{ pipeline: $UPSTREAM_PIPELINE_ID, job: build }]`, including how to pass the upstream pipeline id downstream (dotenv var, `trigger` forwarding).

4. **CI_JOB_TOKEN scoping** — the security model: configure the upstream project's "CI/CD job token allowlist" to permit the downstream project, and why this is required since the token-based artifact access tightened. Show the minimal allow-list, not "allow all".

5. **Staleness & determinism** — the trap that `needs:project` grabs *latest* (which may have moved); show how to pin to a tag/commit or pass an explicit version so downstream is reproducible.

6. **Failure modes** — artifact expired, upstream pipeline failed, ref has no successful pipeline, token denied — and the error each produces, with the fix.

7. **Validation** — a test proving the downstream job receives the expected files and version, and a fallback if the upstream artifact is missing.

Output as: (a) the exact `needs:` stanza for my case, (b) the CI_JOB_TOKEN allow-list config, (c) a version-pinning pattern for determinism, (d) an artifact-missing fallback, (e) a cross-pipeline debug checklist.

Bias toward: minimal token allow-lists, pinned/reproducible refs, explicit failure handling over silent empty artifacts.