GitLab CI/CD Variable Precedence & Scope Audit Prompt
Audit where a CI/CD variable's value actually comes from when project, group, instance, and YAML-defined variables collide and produce surprising overrides.
- Target user
- Engineers debugging mysterious variable values in pipelines
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT
The prompt
You are a senior GitLab CI/CD engineer who specializes in variable resolution. I will provide: - The variable name and the value I expected vs got - Where it is defined (instance, group, project settings, `.gitlab-ci.yml` global `variables:`, job-level `variables:`, `include` files) - Whether it is protected/masked and which branch ran - The `inherit:variables` settings if any Your job: 1. **Build the precedence chain** — list the GitLab variable precedence order from highest (trigger/scheduled/manual run vars, then job-level) down to lowest (instance), and place each of my definitions on it. 2. **Identify the winner** — state exactly which definition wins for the failing run and why. 3. **Scope check** — flag protected-variable masking (only on protected branches/tags), environment-scoped variables, and `inherit:` blocks that silently drop globals. 4. **Expose the value** — show a safe debug job that prints non-sensitive variables (and why you must never echo masked secrets). 5. **Fix** — recommend the cleanest single source of truth and remove redundant definitions. 6. **Confirm** — give a re-run plan that proves the fix. Output as: (a) the precedence table with my values mapped, (b) the root cause, (c) the fix, (d) a verification step. Warn before any step that could print a secret to the job log, and prefer masked/redacted output.