GitLab CI/CD trigger:forward Variable Inheritance Control Prompt
Take precise control of what a downstream pipeline inherits using trigger:forward — deciding whether YAML-defined and pipeline (manual/scheduled) variables flow into child and multi-project pipelines, so secrets don't leak downstream and child pipelines get exactly the inputs they need.
- Target user
- Engineers orchestrating child and multi-project pipelines
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a GitLab pipeline orchestration engineer who controls exactly which variables cross from a parent pipeline into its downstream pipelines using trigger:forward.
I will provide:
- The trigger relationship (child pipeline via `trigger: { include: ... }`, or multi-project via `trigger: { project: ... }`)
- Which variables the downstream pipeline genuinely needs
- Which variables must NOT cross (secrets scoped to the parent, environment-specific tokens)
Your job:
1. **Forwarding model** — explain the two forwarding switches: `trigger:forward:yaml_variables` (variables defined in the trigger job's YAML) and `trigger:forward:pipeline_variables` (variables that came from manual run, schedule, or API). State the defaults (yaml on, pipeline off) and why the pipeline default is a safety feature.
2. **My config** — write the `trigger:` block with `forward:` set so the downstream gets exactly what it needs and nothing more. Show explicit `variables:` on the trigger job for inputs you want to pass deliberately.
3. **Secret-leak guard (CRITICAL)** — call out that turning `pipeline_variables: true` forwards manually-entered and scheduled variables downstream, which can push parent-scoped secrets into a multi-project pipeline in another project. Recommend passing only explicit, named variables instead of bulk-forwarding.
4. **Precedence** — clarify how forwarded variables interact with variables the downstream defines itself (who wins) so I don't get surprised overrides.
5. **Multi-project trust** — for cross-project triggers, note the trust boundary: the downstream project's maintainers see whatever you forward; treat it like an API call.
6. **Verify** — give a downstream debug job that echoes the expected (non-secret) inputs and confirms the forbidden ones are absent.
Output: (a) the forwarding explanation with defaults, (b) the corrected `trigger:` + `variables:` block, (c) the secret-leak guardrail, (d) the precedence notes, (e) the downstream verify job.
Bias toward: forwarding explicit named variables over bulk forwarding, and keeping pipeline_variables off across project boundaries.
Why this prompt works
trigger:forward looks like a minor convenience toggle until you realize it controls a trust boundary. There are two independent switches — yaml_variables for variables defined in the trigger job, and pipeline_variables for variables that arrived via manual run, schedule, or API — and they have deliberately different defaults. YAML variables forward by default because you wrote them on purpose; pipeline variables do not forward by default because they often include secrets and per-run inputs that shouldn’t silently cascade. People flip pipeline_variables: true to fix a “missing variable downstream” without realizing they just opened a channel that pushes manually-entered tokens into a child or, worse, a multi-project pipeline in another team’s project. This prompt makes that defaults-and-consequences model explicit so the fix is scoped, not blanket.
The better pattern — and the one the prompt biases toward — is passing explicit, named variables on the trigger job rather than bulk-forwarding everything. That gives the downstream exactly the inputs it needs, keeps the interface legible, and means nobody has to audit “what could possibly be in the pipeline variable set today.” For cross-project triggers especially, this matters because forwarded values land in another project’s job logs, which the prompt frames correctly as an API call across a trust boundary rather than an internal detail.
Precedence is the last sharp edge. Forwarded variables interact with whatever the downstream defines itself, and the resolution order isn’t intuitive, so you can get silent overrides that change deploy behavior. By making the model spell out who wins and provide a downstream verify job that both confirms the wanted inputs and proves the forbidden ones are absent, you ship an orchestration change you can actually trust — instead of discovering the leak the day a scheduled run forwards a prod token into a sandbox project.