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.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
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.
Related prompts
-
GitLab CI/CD Downstream dotenv Variable Passing Prompt
Pass computed values (image tag, version, environment URL) from an upstream job into a downstream/child pipeline using dotenv artifacts and trigger inheritance, instead of fragile re-computation or hardcoding.
-
GitLab CI/CD Downstream Trigger Variable Forwarding Prompt
Design and debug how variables propagate to downstream and multi-project pipelines using trigger:forward, so the right values reach child pipelines without leaking everything by accident.
-
GitLab CI/CD Manual Run Variable Input Form Prompt
Turn ad-hoc manual pipeline runs into a guided form using variables: with value, description, and options so operators pick from a dropdown of valid choices instead of typing free-text into a 'Run pipeline' box and fat-fingering a prod deploy.
-
GitLab CI/CD variables:expand:false Raw & Nested Variable Prompt
Stop GitLab from mangling secrets and tokens that contain dollar signs or look like variable references by using variables:expand:false (raw variables), and design intentional nested expansion where you actually want it.
More GitLab CI/CD prompts & error guides
Browse every GitLab CI/CD prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.