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.
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.