Manual Pipeline Inputs

Use GitLab Run pipeline when you need to run the manual release-lane flow with explicit input values instead of relying on the normal branch-driven develop promotion path.

This page is written as a single Confluence-ready reference for:

• what each pipeline input means
• which branch/ref combinations are allowed
• how to start the pipeline from GitLab's UI
• where to add screenshots later

Screenshot placeholder: GitLab Run pipeline page with the branch selector and input fields visible.

When To Use This

Use manual pipeline inputs when all of the following are true:

• you are starting the pipeline from GitLab's Run pipeline UI
• you want to deploy a release/* branch through the manual release lane
• you want the pipeline to show only the deploy path for one selected target environment

Do not use manual inputs for normal develop promotion-lane deploys. develop remains the source of truth for the governed dev -> qa -> uat -> staging -> production promotion flow.

Available Inputs

Input	Type	Allowed Values	Purpose
target_env	string	"", dev, qa, uat, staging, prod	Selects the target environment for the manual pipeline
run_migrations	boolean	false, true	Exposes the matching manual migration job when supported for the selected target

target_env

Value	Meaning	Branch Guardrail	Current Behavior
""	No manual deploy intent	N/A	Pipeline follows normal branch-driven behavior
dev	Manual release-lane deploy to dev	release/* only	Supported
qa	Manual release-lane deploy to QA	release/* only	Supported
uat	Manual release-lane deploy to UAT	release/* only	Supported
staging	Higher-environment manual target	release/* only	Input is available and validated; downstream deploy job rollout is tracked separately
prod	Higher-environment manual target	release/* only	Input is available and validated; downstream deploy job rollout is tracked separately

run_migrations

Value	Meaning
false	No manual release-lane migration job is exposed
true	The matching manual release-lane migration job is exposed when that target is currently supported

Guardrails

The manual pipeline input flow is intentionally strict:

• it must be started from GitLab's Run pipeline UI
• it must target a release/* branch
• develop should not use inputs because develop already owns the branch-driven promotion path
• staging and prod are release-branch-only targets and fail fast if a non-release/* ref is selected

If the branch or input combination is invalid, the pipeline fails before expensive image build work starts.

Current Rollout Status

The input contract now includes higher-environment values so operators can see the full target model in one place, but job rollout is still phased.

target_env	Validation	Build Path	Deploy Job Today
dev	Yes	Yes	deploy-dev-release
qa	Yes	Yes	deploy-qa-release
uat	Yes	Yes	deploy-uat-release
staging	Yes	Yes	Placeholder for the higher-environment release-lane rollout
prod	Yes	Yes	Placeholder for the higher-environment release-lane rollout

Screenshot placeholder: Pipeline graph showing a successful target_env=qa run with only one release-lane deploy job visible.

How To Run The Pipeline From GitLab

1. Open the goosehead-fastlane project in GitLab.
2. Navigate to Build > Pipelines.
3. Click Run pipeline.
4. In Run for branch name or tag, select the release/* branch you want to deploy.
5. In the pipeline inputs section, set target_env to the environment you want.
6. Set run_migrations=true only if you want the matching manual migration job to appear for a supported target.
7. Click Run pipeline.

Screenshot placeholder: Completed Run pipeline form with target_env selected and run_migrations toggled.

What The Pipeline Validates

After the pipeline starts, the validation layer checks:

• the pipeline source is GitLab web UI
• the selected ref is a release/* branch
• the selected target_env is supported by the input contract
• required deploy secrets are available to the pipeline

For staging and prod, the validation error should clearly explain that those targets are release-branch-only.

What Jobs To Expect

For currently supported lower environments, only the matching release-lane deploy job should appear:

Selected Input	Deploy Job	Migration Job When run_migrations=true
target_env=dev	deploy-dev-release	run-migrations-dev-release
target_env=qa	deploy-qa-release	run-migrations-qa-release
target_env=uat	deploy-uat-release	run-migrations-uat-release

For staging and prod, operators should currently treat the input values as guarded higher-environment options in the contract. Coordinate with the CI/CD owner before using those values until the dedicated deploy jobs are enabled in the rollout.

Common Invalid Combinations

Scenario	Expected Result
feature/foo with target_env=dev	Fails during validation
feature/foo with target_env=staging	Fails during validation with a release-branch-only message
develop with any target_env input	Should not be used; rely on branch-driven deploy jobs instead
Git push pipeline with target_env=qa	Fails because the manual lane must start from Run pipeline

Screenshot placeholder: Validation failure message for a non-release/* branch attempting target_env=prod.

Operator Notes

• Use this flow for targeted release-lane validation, not for normal develop promotion.
• Use run_migrations=true only when the selected target's manual migration job is part of the current rollout.
• If you need staging or production behavior beyond input validation and selection, confirm the higher-environment release-lane jobs are enabled before running the pipeline.