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.
- Target user
- Engineers building safe operator-facing manual pipelines
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a GitLab CI UX engineer who turns risky free-text manual pipeline runs into a guided, validated form using the variables: prefilling and options feature. I will provide: - The manual/operator pipeline and what inputs it takes (e.g., TARGET_ENV, VERSION, DRY_RUN) - Which inputs have a fixed set of valid values - Which inputs are dangerous if wrong (e.g., TARGET_ENV=production) Your job: 1. **Prefilled descriptions** — write the top-level `variables:` long form with `value:` (default), `description:` (shown in the Run-pipeline UI), so each input is documented at the point of use. Show the YAML. 2. **Dropdown options (CRITICAL)** — for inputs with a fixed value set, add `options:` so the Run-pipeline form renders a dropdown and the operator cannot type an invalid value (e.g., TARGET_ENV limited to `staging`/`production`). Ensure the default in `value:` is one of the `options:`. 3. **Dangerous-default safety** — make the safe choice the default (e.g., DRY_RUN=true, TARGET_ENV=staging) so an accidental "Run" without reading does the harmless thing. 4. **Gate the action** — pair the inputs with `rules:`/`when: manual` and an environment so production selection still requires the manual deploy gate and protected-environment approval, not just a dropdown. 5. **Validation fallback** — for free-text inputs that can't be options (e.g., VERSION), add an early `script` check that validates the format and fails fast with a clear message. 6. **Verify** — describe what the Run-pipeline form should look like (dropdowns, descriptions, safe defaults) and how to confirm an invalid value is impossible or rejected. Output: (a) the `variables:` block with `value`, `description`, and `options`, (b) the safe-default rationale, (c) the manual/environment gating, (d) the validation script for free-text inputs, (e) the form verify. Bias toward: dropdowns over free text, the safest choice as default, and keeping protected-environment approval in place even with a nice form.
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
The GitLab “Run pipeline” box is where good intentions go to fat-finger production. Operators type TARGET_ENV=prodcution, or set a version that doesn’t exist, or leave a dangerous flag on because nobody told them the default mattered. GitLab’s variables: long form fixes the ergonomics: description: documents each input right in the form, value: sets a default, and options: renders an actual dropdown so invalid values become impossible to enter. This is a small feature with an outsized safety payoff, and it’s underused because most people only know the one-line KEY: value form. The prompt makes the model emit the full long form with options wired correctly, including the easy-to-miss rule that the default value: must be one of the options:.
The design judgment the prompt enforces is making the safe choice the default. A guided form still does damage if the path of least resistance is a prod deploy with dry-run off. Defaulting DRY_RUN=true and TARGET_ENV=staging means the operator who clicks Run without reading triggers the harmless path, and has to deliberately choose the dangerous one. That single principle prevents a whole class of “I didn’t realize it would actually deploy” incidents.
Crucially, the prompt refuses to let a nice form masquerade as access control. A dropdown stops typos; it does not stop an unauthorized person from selecting production. So it keeps when: manual, the environment:, and protected-environment approval in the loop, and adds a format-validation script for the free-text inputs that can’t be dropdowns. The result is a manual pipeline that’s pleasant to operate and still gated where it counts — rather than a polished UI that gives a false sense of safety over an unprotected deploy.
Related prompts
-
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.
-
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.
-
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.
-
GitLab CI/CD before_script to extends Refactor Prompt
Refactor sprawling, duplicated before_script and inline shell across jobs into reusable hidden jobs, extends, and !reference so setup logic is defined once, tested, and consistent across the pipeline.
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.